Bug 204600 - SDL i386 library isn't linked properly against x11
SDL i386 library isn't linked properly against x11
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: SDL (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
:
Depends On:
Blocks: FC6Blocker
  Show dependency treegraph
 
Reported: 2006-08-30 07:03 EDT by Matthias Saou
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-25 11:33:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthias Saou 2006-08-30 07:03:28 EDT
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.
Comment 1 Hans de Goede 2006-09-25 05:35:16 EDT
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.
Comment 2 Hans de Goede 2006-09-25 05:46:19 EDT
As promised the problem of the dlopening not happening on x86_64 has been
reported as a new bug, see bug 207903.
Comment 3 Matthias Saou 2006-09-25 11:12:30 EDT
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...
Comment 4 Thomas Woerner 2006-09-25 11:33:35 EDT
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".
Comment 5 Hans de Goede 2006-09-26 01:27:24 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.