[lsb-discuss] Lacking Standard Symlinks in Linux Standards Base
Wichmann, Mats D
mats.d.wichmann at intel.com
Fri Aug 25 05:49:11 PDT 2006
>Hello - there was a discussion few days ago on openSUSE mailing lists
>The main problem is that moving between Windows versions you get 90%
>of compatibility and on Linux only 30% of compatibility.
This is an interesting pair of numbers, but what do they mean?
What is "30% of compatibility" and how is it measured?
>I have made some test with klik - a new package manager that can
>install Debian Software on any RPM-based Linux out there. And found
>that while it works nice on SUSE (80% success) it fails miserably on
>Fedora (with 30% success).... after digging a bit I found that there
>are big differences in symlinks between different Linux versions - and
>that hurts compatibility a lot.
>For example on SUSE distro there might be libfoo-1.2.3 with symlink to
>"libfoo" and no such symlink on Fedora. Since you can't have
>cross-Linux app to link against specific lib version you link it vs.
>general API - that is the "libfoo" symlink. Since some symlinks is
>lacking on some distros, some cross-Linux software refuses to run.
>Unfortunately, the latest LSB v3.1 has no standards for symlinks.
If you mean something like this from a typical system:
libncurses.so.5.4 (real file)
libncurses.so.5 -> ncurses.so.5.4
libncurses.so -> ncurses.so.5.4
LSB only specifies the name that will be used at runtime
by way of the DT_NEEDED entries in a program (or library)
binary, which in this cases would be libncurses.so.5.
By convention, Linux packages only install one name for
the library, the others are created by running the
ldconfig command. I happen to know that SuSE runs
ldconfig very aggressively, as I have many times waited
for it to complete after applying package upgrades,
installing new packages, etc. But all of that is really
outside the LSB; as a standard for running application
binaries, it is only interested in the library name
that will be used by the dynamic linker when the program
The mechanism is that at link time you are linked
against libncurses.so, but libcurses.so contains the
runtime name of the library and that is the name
that ends up in the binary.
So either we're okay here, or there is something
I'm not understanding about your concern. Can
you please describe further?
More information about the lsb-discuss