See bug #204594 for a consequence of this problem. On x86_64 : # rpm -q SDL SDL-1.2.10-6.2 # 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) /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000002a96b11000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000002a96d14000) But on i386 : # rpm -q SDL SDL-1.2.10-6.2 # 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) /lib/ld-linux.so.2 (0x56555000) Maybe it's wanted, although I doubt it, but still it should be consistent across both architectures.
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) /lib/ld-linux.so.2 (0x00653000) 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 problem. 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 > problem. 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.