Red Hat Bugzilla – Bug 204600
SDL i386 library isn't linked properly against x11
Last modified: 2007-11-30 17:11:41 EST
See bug #204594 for a consequence of this problem.
On x86_64 :
# rpm -q SDL
# ldd /usr/lib64/libSDL.so
libm.so.6 => /lib64/libm.so.6 (0x0000002a957f9000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000002a95a7c000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000002a95c80000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000002a95f8c000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x0000002a9619d000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x0000002a963a0000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000002a965aa000)
libc.so.6 => /lib64/libc.so.6 (0x0000002a967c4000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000002a96b11000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000002a96d14000)
But on i386 :
# rpm -q SDL
# ldd /usr/lib/libSDL.so
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xf7f29000)
libdl.so.2 => /lib/libdl.so.2 (0xf7f25000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7f0e000)
libc.so.6 => /lib/libc.so.6 (0xf7dd1000)
Maybe it's wanted, although I doubt it, but still it should be consistent across
I believe this new behaviour is intentional, SDL programs still wortk fine with
the new SDL which doesnot link against libX11 even if the program itself also is
not linked against libX11.
I've done a ltrace -S on njam (just an SDL using game as example) whic results
in both library calls and system calls being logged. ldd njam gives:
linux-gate.so.1 => (0x00652000)
libSDL_net-1.2.so.0 => /usr/lib/libSDL_net-1.2.so.0 (0x00446000)
libSDL_mixer-1.2.so.0 => /usr/lib/libSDL_mixer-1.2.so.0 (0x00b03000)
libSDL_image-1.2.so.0 => /usr/lib/libSDL_image-1.2.so.0 (0x00111000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x0012b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00621000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00ceb000)
libm.so.6 => /lib/libm.so.6 (0x007b1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0050e000)
libc.so.6 => /lib/libc.so.6 (0x001d4000)
libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x004aa000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x007fc000)
libogg.so.0 => /usr/lib/libogg.so.0 (0x00478000)
libmikmod.so.2 => /usr/lib/libmikmod.so.2 (0x00b4e000)
libdl.so.2 => /lib/libdl.so.2 (0x00311000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00734000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00315000)
libz.so.1 => /usr/lib/libz.so.1 (0x005bd000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x00c7a000)
Notice how libX11 is missing, which should lead to njam not running since its
pretty crucial to have libX11. However njam runs fine, here is an interesting
part of the log from ltrace -S:
SDL_Init(49, 0x8056364, 1, 0x8e54025, 0 <unfinished ...>
SYS_futex(0x97a06c, 1, 0x7fffffff, 0, 0x2171ac) = 0
SYS_open("/etc/ld.so.cache", 0, 022000000001) = 3
SYS_fstat64(3, 0xbfbdf370, 0xa8cfc0, -1, 3) = 0
SYS_mmap2(0, 81699, 1, 2, 3) = 0xb7f30000
SYS_close(3) = 0
SYS_open("/usr/lib/libX11.so.6", 0, 01562) = 3
SYS_read(3, "\177ELF\001\001\001", 512) = 512
Notice how ld.so.cache and then libX11.so.6 get opened after SDL_Init is called,
also notice the <unfinished ...>, iow they get called from within SDL_Init. I
believe that libSDL-1.2.so.0 is no longer linked against libX11.so.6 and instead
it dlopen's it when needed. This means that SDL now can be used without X
installed for example on framebuffer targets.
To verify my hypotesis I've also checked the SDL changelog to quote a very
relevant change for 1.2.10:
* The X11 libraries are dynamically loaded at runtime by default. This allows
the distributed version of SDL to run on systems without X11 libraries installed.
Thus this is not a bug, but a feature! The only bug is the question why on
x86_64 SDL is still linking hard against libX11.so.6 instead of using dlopen as
it does on i386 and ppc. This "real bug" (tm) has caused confusion leading to
this wrong bug report.
Thus I believe this bug should be closed and I shall open a new one for the real
With regards to the failed build of fillets-ng that is because fillets-ng makes
a few X11 calls directly from the fillets-ng source and since it is using X11
directly it should also have -lX11 on its linking cmdline, which it doesn't. The
fact that it was previously working because libSDL drew in libX11 into the
linking was just luck. Matthias if you agree with me on my an analysis of this
please close this bug.
As promised the problem of the dlopening not happening on x86_64 has been
reported as a new bug, see bug 207903.
I don't think it was really worth filing another bug for this exact same
problem. Anyway, a fix before FC6 final would be nice...
The x86_64 version has problems with the X11 libs for dynamic loading in the
build system. The i386 version does not have that problem and is ok.
Closing as "NOT A BUG".
(In reply to comment #3)
> I don't think it was really worth filing another bug for this exact same
It is not the exact same problem, at first we (you and I) though that the
problem was that libSDL-1.2.so.0 was not linked against libX11.so.6 (and
friends) on i386 (and ppc), as the Summart of this bug says, however that is not
a bug but a feature. The only bug here is that the x86_64 does not have that
feature, which is a different issue thus a new bug.
> Anyway, a fix before FC6 final would be nice...
A fix for x86_64 not having this issue you mean thats unlikely since that is
very low impact and FC-6 is in bug fix only mode.
Also fillets-ng does not need an SDL fix, instead it needs to be fixed itself to
include -lX11 on the cmdline when linking.