Colin Barrett
Using the pre-built x86 devel libs from here:
https://www.libsdl.org/release/SDL2-devel-2.0.5-VC.zip
If I have:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_DEBUG_FLAG);
and I'm using ANGLE/(a GL driver that doesn't provide an ES2 context) such that SDL_EGL_CreateContext is called by SDL_GL_CreateContext, I get the error "Could not create EGL context (context attributes are not supported)" and no context is created.
Looking at the code in SDL_EGL_CreateContext - if gl_config.flags is non-zero, it looks like the code in the section guarded with "#ifdef EGL_KHR_create_context" should be executed - but it apparently isn't.
Is it possible this section hasn't been compiled into the pre-built libraries? If I build SDL2.dll myself using the Visual C++ solution (VS2015 Community Update 3) then the call succeeds as I expect
sfalexrog
Android haptic code was not added to CMakeLists.txt, leading to build failures when targeting Android platform.
Attached patch adds Android haptic driver to source sets and adds configuration parameter to SDL_config.h.cmake.
Tom Seddon
0f0ad62237 (git head at the time of writing); Visual Studio 2015, toolset v140, Platform 10.0.14393.0, building for x64
Windows non-MinGW cmake build sets defines implying wcslcpy and wcslcat are available, but Windows doesn't have these functions.
Ryan C. Gordon
That's weird, these are the exact two functions that Emscripten incorrectly believed it had until we upgraded the buildbot's emsdk install.
Not sure what's up with this, but it's possibly not a MingW-specific thing!
manuel.montezelo
Original bug report (note that it was against 2.0.0, it might have been fixed in between): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733015
--------------------------------------------------------
Package: libsdl2-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal
Tags: patch
I have occasional crashes here caused by the X11 backend of SDL2. It seems to
be caused by the X11_Pending function trying to add a high number (> 1024)
file descriptor to a fd_set before doing a select on it to avoid busy waiting
on X11 events. This causes a buffer overflow because the file descriptor is
larger (or equal) than the limit FD_SETSIZE.
Attached is a possible workaround patch.
Please also keep in mind that fd_set are also used in following files which
may have similar problems.
src/audio/bsd/SDL_bsdaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/qsa/SDL_qsa_audio.c
src/audio/sun/SDL_sunaudio.c
src/joystick/linux/SDL_sysjoystick.c
--------------------------------------------------------
On Tuesday 24 December 2013 00:43:13 Sven Eckelmann wrote:
> I have occasional crashes here caused by the X11 backend of SDL2. It seems
> to be caused by the X11_Pending function trying to add a high number (>
> 1024) file descriptor to a fd_set before doing a select on it to avoid busy
> waiting on X11 events. This causes a buffer overflow because the file
> descriptor is larger (or equal) than the limit FD_SETSIZE.
I personally experienced this problem while hacking on the python bindings
package for SDL2 [1] (while doing make runtest). But it easier to reproduce in
a smaller, synthetic testcase.
tschwinger@elitemail.org
Most ironically, although autoconf/automake-based builds install (pretty half-assed) CMake package configuration files, they're missing in installations resulting from CMake-based builds entirely.
A proper configuration file typically also loads target exports (implemented in patch 3572, also fixing this issue - see my comment on that issue for details).
I believe it would be best to let the dinosaurs go extinct and redirect all build efforts to the CMake end for two reasons:
1. It potentially provides the best user experience, but you'd have to give it some love and ship with less quirky buildfiles.
2. It would force distros to build SDL via CMake and thus would ensure target exports are actually available everywhere.
Various CMake patches I submitted today in summary (directly converted from the HG commits and `am`d onto a fork of a git mirror that happened to be on `tip`).
https://github.com/tschw/SDL/commits/patched
Fixing #2576#3572, #3613, and this fresh ticket, which is almost entirely advertisement ;).
These already do to make SDL much less of a quirky fella to have in your dependency tree...
-Enabling checking for GCC_ATOMICS also on clang by default. This way all Android ABIs build successfully
-Android cmake: Threading was not enabled correctly
-Android cmake: Timers and dynamic lib loading were not included in the sources
Manuel
The attached patch adds support for KMS/DRM context graphics.
It builds with no problem on X86_64 GNU/Linux systems, provided the needed libraries are present, and on ARM GNU/Linux systems that have KMS/DRM support and a GLES2 implementation.
Tested on Raspberry Pi: KMS/DRM is what the Raspberry Pi will use as default in the near future, once the propietary DispmanX API by Broadcom is overtaken by open graphics stack, it's possible to boot current Raspbian system in KMS mode by adding "dtoverlay=vc4-kms-v3d" to config.txt on Raspbian's boot partition.
X86 systems use KMS right away in every current GNU/Linux system.
Simple build instructions:
$./autogen.sh
$./configure --enable-video-kmsdrm
$make
Ozkan Sezer
(In reply to Ryan C. Gordon from comment #9)
> I've put this patch in as https://hg.libsdl.org/SDL/rev/7213ae46e870 ...can
> you verify this works on the latest MinGW?
>
> Thanks,
> --ryan.
This patch is wrong: the structure in question has nothing to do with any
gcc version in use. I suggest reverting this adding a conigury check for
it, instead. Something like the following should do it: (configure needs
regenerating.)
Ray Molenkamp
When building sdl as shared lib, the version info is lacking in the final binary.
CMake gathers the right resource files into ${VERSION_SOURCES} but then doesn't do anything with them.
Timo Gurr
On cross hosts running autotools for SDL2_gfx-1.0.1 fails to find sdl2.m4:
eautoreconf: running in /var/tmp/paludis/build/media-libs-SDL2_gfx-1.0.1/work/SDL2_gfx-1.0.1 ...
aclocal
aclocal-1.13: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:128: warning: macro 'AM_PATH_SDL2' not found in library
libtoolize --copy --force --automake
aclocal
aclocal-1.13: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:128: warning: macro 'AM_PATH_SDL2' not found in library
autoconf
configure.in:128: error: possibly undefined macro: AM_PATH_SDL2
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
* Failed Running autoconf !
SDL2 installs it to /usr/x86_64-pc-linux-gnu/share/aclocal on cross hosts, attached patch makes use of CMAKE_INSTALL_FULL_DATAROOTDIR to support correctly installing to the arch independent location /usr/share/aclocal.
joe.gsoc16
I recently looked into Unicode support in SDL2 and realized that
SDL_TEXTEDITING doesn't get triggered at all (Japanese IME).
According to others on IRC it works fine on Windows/Mac but not
for me on (arch)Linux.
When compiling SDL with autotools, IBus support is enabled by
default but not so with CMake.
I never used CMake before but got it working and also included
that pkg-config determines flags for dbus (FIXME in CMakeLists).
Sam Lantinga
Ryan C. Gordon
Olli Kallioinen
Alex Szpakowski
Jukka Jyl?nki
Charlie Birks