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 :)
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.
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.
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.
It was very confusing to have configure generate an SDL_config.h and then not have it be used when building on Mac OS X or Windows. I'll just have to remember to use SDL_config_windows.h when building official releases that are supposed to be ABI compatible with Visual Studio.
--HG--
rename : include/SDL_config_generated.h.in => include/SDL_config.h.in
Scott Percival 2011-07-03 06:41:51 PDT
This submission is aimed at making life easier for OpenGL ES capable devices
running a X11 stack (e.g. Maemo, Meego, TrimSlice, other ARM SoC boards not
running Android). SDL's Pandora support already has the neccesary GLES-to-X11
glue code, however it's all ghetto'd off in Makefile.pandora and not very
flexible.
The patch:
- adds an awesome --enable-video-opengles option to configure
- re-modifies the opengles and opengles2 SDL_renderers to use function pointers
- no idea why this was removed?
- for SDL_Renderers, links in libGLESv1_CM, libGLES_CM (for PowerVR fans) or
libGLESv2 at runtime
- links in libEGL.so at runtime - the old code made an assumption that
eglFunctions could be pulled from the active GLES library, PowerVR for one
doesn't let you do that with their libGLESv2
- allows you to pick which of GLES v1 or v2 to load via
SDL_GL_CONTEXT_MAJOR_VERSION
So far I've tested this on a Nokia N900 (OMAP 3430/SGX 530 running Maemo 5) and
a Toshiba AC100 (Tegra 2 running Ubuntu 10.10). I haven't tested it on... well,
everything that isn't those two, such as a Pandora, iOS or Android device. The
Pandora specific code should be kept intact (fingers crossed), and nothing
painfully drastic has been added to the SDL_renderers. The library loading
sequence in SDL_x11opengles has been updated to accomodate both NVIDIA's
propensity to let developers get away with murder and PowerVR's alternative of
punishing every missed step.
The test apps work okay with GLES or GLES2 as the renderer. For some reason
alpha blending doesn't seem to work on the Tegra 2; last week NVIDIA pushed out
a new set of X11 GLES drivers, so I'll try and investigate once I upgrade
those. Also, this patch adds things to configure.in, include/SDL_config.h.in
and test/configure.in. I didn't know what the policy was re. committing
generated spaghetti from autotools, so ./autogen.sh has to be run again. Sorry.
I think that's about everything, let me know if there's anything I've
overlooked.
