GCC 3.2.2

Kelledin kelledin+LFS at skarpsey.dyndns.org
Thu Feb 6 18:29:34 PST 2003


On Thursday 06 February 2003 06:07 pm, torsten wrote:
> libstdc++ is the problem.  Mozilla binary is compiled againt
> it dynamically,
> obviously not the version with my compiler.  I just create a
> symlink, and
> mozilla seems to be happy.
>
> This may be a "purity" issue - having binaries linked to old
> libraries does
> not sit well with me.

It should work if the source code is maintained properly.  The 
way it's supposed to work is this:

Every dynamic library exports a certain ABI.  Every dynamic 
library also embeds a SONAME tag; when ld links a binary with a 
dynamic library like libpng.so, it will link the binary to the 
name in libpng's SONAME field (libpng.so.3) rather than the 
actual filename (libpng.so).

Theoretically (if the library developer does his job), all 
libraries which embed the same SONAME will have a pretty good 
degree of ABI compatibility--you're supposed to be able to 
update the library, and if the SONAME is still the same in the 
new version, binaries should work without relinking.  If the 
SONAME is different, binaries depending on the old library will 
just absolutely refuse to run, complaining about missing 
libraries.  So problems caused by ABI incompatibility are 
avoided--or at least, they show up immediately, are perfectly 
reproducible, and are easy to track down.

In practice, this _usually_ works.  Not always though.  Some 
libraries provide a different ABI depending on whether they're 
configured for, say, i486 or athlon, but their SONAME doesn't 
change.  Usually if this problem comes up, the binary will just 
fail to work at run-time, with the run-time linker complaining 
about missing such-and-such relocation symbol.

Then, there's another issue--how well this system works depends 
on how well the developer keeps the ABI stable.  If a developer 
breaks ABI compatibility, he's supposed to make sure the SONAME 
changes, but developers don't always do what they're supposed 
to. ;)

The only way to be 100% sure of avoiding these problems is to 
relink all dependent binaries/libraries every time you do a 
library update.  Of course, this is a lot of work.  Many 
big-name distros like RedHat have an automated system where 
their current distro-in-development has all RPMs recompiled 
periodically from the ground up, just to avoid problems like 
this.  Needless to say, they probably have very powerful 
clusters doing distributed compiles just to cut down on the 
build time.

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list