Andreas
With the patch applied, make is not able to find the rule for Makefile.in anymore. Removing the patch resolves the issue.
The path is in fact correct (in my case: /c/external/SDL64/SDL). But it seems the windows build of GNU Make doesn't work well with pathnames in rules. Both the dependencies in "$(srcdir)/configure: $(srcdir)/configure.in" and "Makefile: $(srcdir)/Makefile.in" will cause rules not to be found when srcdir is defined.
The same problem occurs if the patch is removed and I supply configure with a srcdir manually.
The configure script was still overwriting SIZEOF_VOIDP so both ended up as either 4 or 8 depending on the arch. This simply removes the check from configure.in
This #errors if you're using an SDK or deployment target that is less
than 10.6 and 10.5, respectively, and cleans up uses of
MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED according
to those requirements.
Unexplicable computer sciences phenomenon: Instead of returning an empty set,
*.c in an folder with no .c files produces the "*.c" string to be added as
a source. I'm sorry future generations, we are doing the best we can :)
Axel Dörfler
Currently, the default install target for Haiku is /boot/develop/tools/gnupro. However, this is not the expected install place. Instead, /boot/common should be used.
leighmanthegreat@hotmail.com
I downloaded SDL2 from hg source.
I built to a ./build directory.
I downloaded SDL_image 2 hg and attempted to build.
When it cannot find a sdl2-config the SDL_image configure correctly suggests setting SDL_CONFIG variable.
Setting this the configure still fails with 'Permission denied' on the call to sdl2-config.
Setting execute permission solves the problem.
If possible, sdl2-config should have executable bit set when it is created.
tomaszewski.p
Recent changes in SDL_sysrenderer.h and SDL_sysvideo.h had no impact on directfb backend.
Attached patch:
- updates interface,
- resolves uninitialized variable reading,
- changes logging tio use SDL_Log API,
- updates configure to use DIRECTFBCONFIG variable instead direct call to directfb-config.
This uses libudev for hotplug, but it's optional, so we'll just try to find
some reasonable defaults without it (maybe an older Linux box or under
FreeBSD's Linux emulation?).
The OpenBSD case is puzzling - it's complaining about symbols in the C library. Do we need to explicitly link with -lc for shared libraries on OpenBSD?
The BeOS case is legitimate, it's calling back into the application code to initialize BeApp if it isn't already initialized.
It's a long-dead platform, and we don't have any way to build for, test, or
maintain it, so there's no sense in doing acrobatics to support it.
If you need Windows CE support, use SDL 1.2. If you need Windows Phone support,
send SDL 2.0 patches for the newer Windows Mobile platform.
Brad Smith 2012-07-19 11:39:09 PDT
I noticed this error from the OpenBSD/amd64 buildbot log..
../configure[15018]: test: -O2: unexpected operator/operand
The attached patch fixes the issue.
