There are two issues which are stopping the SDL tests from building on
my machine:
- libunwind is not being linked
- Even if it is, it is missing several symbols.
The first is fixed by having the test programs link against libunwind if
available. Technically, SDL2_test should be linking against it, as it's
used in SDL_test_memory.c, but as SDL2_test is a static library, it
can't itself import libunwind. We just assume that if it's present on
the system, we should link it directly to the test programs. This should
strictly be an improvement, as the only case where this'd fail is if
SDL2 was compiled when libunwind was present, but the tests are being
compiled without it, and that'd fail anyway.
The second is fixed by #define-ing UNW_LOCAL_ONLY before including
libunwind.h: this is required to make libunwind link to predicatable
symbols, in what can only be described as a bit of a farce. There are a
few more details in the libunwind man page, but the gist of it is that
it disables support for "remote unwinding": unwinding stack frames in a
different process (and possibly from a different architecture?):
http://www.nongnu.org/libunwind/man/libunwind(3).html
Note that I haven't tried this with CMake: I suspect that it'll work,
though, as the CMakeLists.txt seems to have SDL2 link against libunwind if
it's present. This adds an ugly extra dependency to SDL2, but does mean
that issue 1 isn't present. The UNW_LOCAL_ONLY change shouldn't be
build-system-specific.
The version with an implicit pattern rule tended to fail if test/
was built in an "out-of-tree" build directory not below test/, for
example:
cd SDL
mkdir _build-test
( cd _build-test; ../test/configure )
make -C _build-test
as a result of the pattern rule first checking for axis.bmp, then for
../test/axis.bmp, then ../test/../test/axis.bmp, and so on until the
maximum path length was reached.
Note that this requires GNU make. The FreeBSD ports file for SDL seems
to use GNU make (gmake) already, so presumably SDL's build system is
already relying on GNU make extensions.
Signed-off-by: Simon McVittie <smcv@debian.org>
AC_CONFIG_AUX_DIRS is an undocumented, internal version of
AC_CONFIG_AUX_DIR that takes a whitespace-separated list, instead of a
single path to add to the list. It also does not automatically treat
the given path as being relative to the $srcdir, unlike the documented
AC_CONFIG_AUX_DIR.
Newer versions of autoconf treat the argument to AC_CONFIG_AUX_DIRS
as being literal (they do not expand the shell variable), causing
autoreconf to fail if $srcdir is explicitly specified. The argument to
AC_CONFIG_AUX_DIR is checked relative to $srcdir anyway, so there is no
need to specify $srcdir a second time.
Resolves: https://github.com/libsdl-org/SDL/issues/4719
Signed-off-by: Simon McVittie <smcv@debian.org>
[--use-rendergeometry mode1|mode2]
mode1: Draw sprite2 as triangles that can be recombined as rect by software renderer
mode2: Draw sprite2 as triangles that can *not* be recombined as rect by software renderer
Use an 'indices' array
There were a few places throughout the SDL code where values were
clamped using SDL_min() and SDL_max(). Now that we have an SDL_clamp()
macro, use this instead.
On Wayland -- or at least on some Wayland implementations -- windows
aren't shown until something has been rendered into them. For the
'checkkeys' test program, this means that keyboard input isn't
registered, making the program rather useless.
By creating a renderer and presenting once, the window is properly
displayed, and the test behaves as it does under X11 (including
XWayland).
The exact same thing was done with testmessge in 1cd97e2695 (PR #4252)
SDL_Vulkan_GetDrawableSize() doesn't always return a size which is
within the Vulkan swapchain's allowed image extent range.
(This happens on X11 a lot when resizing, which is bug #3287)
Clamp the value we get back from SDL_Vulkan_GetDrawableSize() to this
range. Given the range usually is just a single value, this is almost
always equivalent to just using the min or max image extent, but this
seems logically most correct.
If you continually poll for events it's possible that new events can come in while you're still processing the last one, delaying rendering. This is more likely with high update rate sensors.
