Jonas Kulla
The configure script didn't differentiate between Linux and Android, unconditionally compiling in the unix implementation of SDL_sysfilesystem.c.
I'm probably one of the very few people building SDL for android using classic configure + standalone toolchain, so this has gone undetected all along.
With this commit, you can compile SDL2 with Emscripten
( http://emscripten.org/ ), and make your SDL-based C/C++ program
into a web app.
This port was due to the efforts of several people, including: Charlie Birks,
Sathyanarayanan Gunasekaran, Jukka Jylänki, Alon Zakai, Edward Rudd,
Bruce Mitchener, and Martin Gerhardy. (Thanks, everyone!)
Chris Beck
When creating a homebrew recipe for wesnoth, I discovered that the SDL image configuration routine does not detect libpng properly -- if you have multiple instances of libpng on your system, and you use environment variables to select an instance which is not in your system directory, the build can be broken, because it will run configuration tests against the system installed version, but deduce that it should use the filename of the system-installed version. In a vanilla build of wesnoth using homebrew, this results in segfaults at runtime, because you end up linking against two different versions of libpng, which is also needed independently of SDL.
The problem is essentially in the "find_lib" routine in the configure file:
find_lib()
{
gcc_bin_path=[`$CC -print-search-dirs 2>/dev/null | fgrep programs: | sed 's/[^=]*=\(.*\)/\1/' | sed 's/:/ /g'`]
gcc_lib_path=[`$CC -print-search-dirs 2>/dev/null | fgrep libraries: | sed 's/[^=]*=\(.*\)/\1/' | sed 's/:/ /g'`]
env_lib_path=[`echo $LIBS $LDFLAGS | sed 's/-L[ ]*//g'`]
for path in $gcc_bin_path $gcc_lib_path $env_lib_path /usr/lib /usr/local/lib; do
lib=[`ls -- $path/$1 2>/dev/null | sort -r | sed 's/.*\/\(.*\)/\1/; q'`]
if test x$lib != x; then
echo $lib
return
fi
done
}
Because the for loop goes over the system directories before the environment directories, any system-installed lib will shadow the lib selected via environment variables. This is contrary to the behavior of the configuration tests earlier in the script, which prefers the environment variable libs over the system-installed libs. The 'for' loop should instead be:
for path in $env_lib_path $gcc_bin_path $gcc_lib_path /usr/lib /usr/local/lib; do
You can see the full discussion on the Homebrew / linuxbrew issue tracker here: https://github.com/Homebrew/linuxbrew/issues/172
I have checked that this bug also affects SDL 1.2.15, SDL_mixer and SDL_ttf 1.2, which all use this same "find_lib" routine. I have not determined if the bug affects SDL 2.0, which seems not to use this exact routine.
Alex Szpakowski
SDL's Cocoa backend uses the CGDisplayMode API to get refresh rate information about a display mode, but CGDisplayModeGetRefreshRate will return 0 on most non-CRT monitors.
The only way I know of to get correct refresh rate information in OS X is via the CoreVideo DisplayLink API.
I have attached a patch which tries to use the CVDisplayLinkGetNominalOutputVideoRefreshPeriod function if CGDisplayModeGetRefreshRate fails, which fixes display mode refresh rate information on the monitors I tested.
The CVDisplayLink API requires linking with the CoreVideo framework, and the patch updates the various build files to do so.
Alex Szpakowski
Now that SDL on iOS requires CoreMotion to be linked, some of the Xcode projects included with the SDL source (such as the iOS tests and the iOS app template) as well as the premake and automake scripts need to be updated.
I've attached a patch which does so. It also fixes the SDL Xcode project to build for 64-bit ARM as well as armv7 by default (or whatever the default ARM targets are for the Xcode version used), which is what the iOS app template expects.
If the EGL extension EGL_KHR_create_context is available, we can use it to
set the core/compatability profile and the minimum OpenGL version.
Use this if it is available to get the context requested by the GL attributes.
I added -Wshadow and then turned it off again because of massive variable shadowing in the blit macros.
Feel free to go through that code and fix these if you want. Just uncomment CheckWarnShadow in configure.in if you want to try this.
Add V=1 to the make command line will show the full commands but by default
we just show the tool-type and the output file. This is generally much easier
on the eye and makes warnings and errors more clearly visible.
The D3D11 renderer is now slightly faster than D3D9 on my Windows 8 machine (testsprite2 runs at 3400 FPS vs 3100 FPS)
This will need tweaking to fix the Windows RT build.
configure wraps this C code in a main() function, so you can't declare a
function body in there. Besides, I'm not sure why we declared a function
that's part of the multitouch API anyhow.
Now we just reference a type that only exists if the headers have multitouch
support and call it a day.
