Compile-time shared library name mismatching base name (SDL)

[Petr Pisar]

Hello list,

I got an interresting report regarging SDL library file names
https://bugzilla.redhat.com/show_bug.cgi?id=962702.

If you install SDL and SDL-devel, you will get these files:

root@fedora-20:~ # ls -o /usr/lib64/libSDL*
lrwxrwxrwx. 1 root     20 Jul  1 10:43 /usr/lib64/libSDL-1.2.so.0 -> libSDL-1.2.so.0.11.4
-rwxr-xr-x. 1 root 444176 Jun 19 12:58 /usr/lib64/libSDL-1.2.so.0.11.4
lrwxrwxrwx. 1 root     20 Jul  1 10:55 /usr/lib64/libSDL.so -> libSDL-1.2.so.0.11.4
root@fedora-20:~ # scanelf --soname /usr/lib64/libSDL*
 TYPE   SONAME FILE 
ET_DYN libSDL-1.2.so.0 /usr/lib64/libSDL-1.2.so.0 
ET_DYN libSDL-1.2.so.0 /usr/lib64/libSDL-1.2.so.0.11.4 
ET_DYN libSDL-1.2.so.0 /usr/lib64/libSDL.so

You can see the symlink for compile-time linking is called libSDL.so
despite the SONAME is libsSDL-1.2.so.0, so the expected file name should
be libSDL-1.2.so.

And that's probably the reason why ldconfig gets confused and wants to
change libSDL-1.2.so.0 symlink from libSDL-1.2.so.0.11.4 to libSDL.so:

root@fedora-20:~ # ldconfig -v |grep SDL
ldconfig: Can't stat /libx32: No such file or directory
ldconfig: Path `/usr/lib' given more than once
ldconfig: Path `/usr/lib64' given more than once
ldconfig: Can't stat /usr/libx32: No such file or directory
        libSDL-1.2.so.0 -> libSDL.so

If I remove the libSDL.so, then ldconfig leaves this silly idea and
returns to expected value (libSDL-1.2.so.0 -> libSDL-1.2.so.0.11.4).

Is this is a bug or a feature of ldconfig?

Is the installed libSDL.so symlink a mistage in the SDL-devel package?

Is renaming libSDL.so to libSDL-1.2.so wise? The libSDL.so is used in
upstream and other distributions.

Is adding the libSDL-1.2.so symlink (and preserving libSDL.so) for
backward compatibility wise?

-- Petr

[Petr Machata]

Petr Pisar  writes:
> Is the installed libSDL.so symlink a mistage in the SDL-devel package?
>
> Is renaming libSDL.so to libSDL-1.2.so wise? The libSDL.so is used in
> upstream and other distributions.

I'm speculating here, but renaming the actual DSO like this would make
it possible to install two runtime SDL versions side by side (say, 1.2
and 2.0).  However, it's safe to assume that you'll only ever need one
SDL-devel, so it's fine to just name the symlink libSDL.so--which allows
you to use -lSDL on compiler command line (instead of having to spell
out -lSDL-1.2).

No idea why it confuses ldconfig like this though.

Thanks,
PM

[Miroslav Lichvar]

On Mon, Jul 01, 2013 at 09:36:19AM +0000, Petr Pisar wrote:
> root@fedora-20:~ # ls -o /usr/lib64/libSDL*
> lrwxrwxrwx. 1 root     20 Jul  1 10:43 /usr/lib64/libSDL-1.2.so.0 -> libSDL-1.2.so.0.11.4
> -rwxr-xr-x. 1 root 444176 Jun 19 12:58 /usr/lib64/libSDL-1.2.so.0.11.4
> lrwxrwxrwx. 1 root     20 Jul  1 10:55 /usr/lib64/libSDL.so -> libSDL-1.2.so.0.11.4
> root@fedora-20:~ # ldconfig -v |grep SDL
> ldconfig: Can't stat /libx32: No such file or directory
> ldconfig: Path `/usr/lib' given more than once
> ldconfig: Path `/usr/lib64' given more than once
> ldconfig: Can't stat /usr/libx32: No such file or directory
>         libSDL-1.2.so.0 -> libSDL.so
>
> If I remove the libSDL.so, then ldconfig leaves this silly idea and
> returns to expected value (libSDL-1.2.so.0 -> libSDL-1.2.so.0.11.4).
> Is adding the libSDL-1.2.so symlink (and preserving libSDL.so) for
> backward compatibility wise?

Perhaps the best option would be to rename the symlink and replace it
with a linker script containing just "INPUT(-lSDL-1.2)" to keep
ldconfig happy. This is how it's done in the ncurses-devel package for
libcurses.

[Florian Weimer]

On 07/04/2013 03:29 PM, Miroslav Lichvar wrote:
> Perhaps the best option would be to rename the symlink and replace it
> with a linker script containing just "INPUT(-lSDL-1.2)" to keep
> ldconfig happy. This is how it's done in the ncurses-devel package for
> libcurses.

Unless I'm missing something, this is fairly common (see the 
attachment).  Perhaps changing ldconfig is better?

[Miroslav Lichvar]

On Thu, Jul 04, 2013 at 05:39:02PM +0200, Florian Weimer wrote:
> On 07/04/2013 03:29 PM, Miroslav Lichvar wrote:
> > Perhaps the best option would be to rename the symlink and replace it
> > with a linker script containing just "INPUT(-lSDL-1.2)" to keep
> > ldconfig happy. This is how it's done in the ncurses-devel package for
> > libcurses.
>
> Unless I'm missing something, this is fairly common (see the
> attachment).  Perhaps changing ldconfig is better?

I think there was a reason why ldconfig did it, but I'm not sure what
it was. You might want to ask the glibc maintainers.
> gpsd-libs-3.9-1.fc19.i686,/usr/lib/libgps.so.20.0,libgps.so.20
> gpsd-libs-3.9-1.fc19.i686,/usr/lib/libgpsd.so.21.0,libgpsd.so.21
> gpsd-libs-3.9-1.fc19.x86_64,/usr/lib64/libgps.so.20.0,libgps.so.20
> gpsd-libs-3.9-1.fc19.x86_64,/usr/lib64/libgpsd.so.21.0,libgpsd.so.21

These look good to me.

[Florian Weimer]

On 07/04/2013 06:14 PM, Miroslav Lichvar wrote:
> > gpsd-libs-3.9-1.fc19.i686,/usr/lib/libgps.so.20.0,libgps.so.20
> > gpsd-libs-3.9-1.fc19.i686,/usr/lib/libgpsd.so.21.0,libgpsd.so.21
> > gpsd-libs-3.9-1.fc19.x86_64,/usr/lib64/libgps.so.20.0,libgps.so.20
> > gpsd-libs-3.9-1.fc19.x86_64,/usr/lib64/libgpsd.so.21.0,libgpsd.so.21
>
> These look good to me.

True.  The attached list (consisting of NEVRA, path of the symlink, and 
the embedded soname of the library to which it links) only contains *.so 
symlinks.  It's still a substantial number.