[lsb-discuss] Some questions on the LSB build environment

Mike Hearn mike at mail.com
Mon Feb 3 02:17:28 PST 2003


> In order to dynamically link against non lsb libraries I think you
> will have to make some modifications to lsbcc or use lsbdev which will
> allow you to more precisely control which libraries are statically or
> dynamically linked. However if your non lsb shared library uses libc
> interfaces not in the LSB then you won't be able to link. 

Is that because ld-lsb.so enforces the link rules of the LSB? If so, is there
any way to disable that for a particular binary?

My reasoning is this: to make binaries that work on most of the popular
distros around today, there are a few big issues:

* glibc symbols: if I compile a binary on a distro with a very new version or
vendor branch of glibc, it'll suck in symvers that aren't present on older
distros. Because glibc changes with pretty much every distro release, the LSB
is a more stable platform to target in this respect, meaning i don't have to
build a binary for redhat8, redhat8.1, suse8, suse8.1, mandrake and so on.

* Symbol namespace pollution: this means that I can't link in two libraries
that offer the same symbol to the same address space, ie:

frozen-bubble game compiled on newest mandrake:
\-> libpng.so.3 (mandrake uses libpng.so.3)
\-> libSDL (distro compiled libSDL against libpng.so.2)
      \-> libpng.so.2

Even though libpng appears in two separate places in the link tree, and so
shouldn't interfere, the breadth-first search algorithm specified by ELF means
they do in fact interfere, causing at best an instant segfault. The only
solution currently is (of course) to recompile on the distro so now it links
against libpng.so.2 like all the other libraries.

That goes contrary to the LSBs mission statement:
"The goal of the LSB is to develop and promote a set of standards that will
increase compatibility among Linux distributions and enable software
applications to run on any compliant Linux system."

So clearly these two problems are big ones from the LSB point of view. The
"core" interfaces that can't easily be upgraded by 3rd parties are already
solved by the use of stub libs and the LSB standardising them, excellent. The
second problem is not solved, and appears to be the reason that the spec
states you have to statically link everything.

Obviously, I can't statically link every library used by most open source
applications, and equally I can't replace every lib on the system with an LSB
compliant version. So - I need to be able to link against the stub libs so the
binaries don't use symvers I can't guarantee are on the system, but I also
need to be able to link against system libraries that were compiled with non
LSB interfaces, even perhaps use optimized glibcs etc, because as they are
already put on the system by the distro they don't really need to be LSB
compliant: they are matched with the glibc.

I think that's a long winded way of putting forward a fairly obvious
problem.... but I'm wondering if the LSB can help me. I can't use it if it's
an all or nothing issue, LSB and non-LSB libs have to be able to co-exist
peacefully in the same process.

thanks -mike




More information about the lsb-discuss mailing list