forestalling GNU incompatibility - proposal for binary relative dynamic linking

[Dan Kegel]

Edward Peschko wrote:
> After spending *two weeks* on various ways of building glibc, 
> I'm convinced that the gnu/linux toolchain is in great danger of 
> losing interoperability.
> 
> The main problem is that the glibc's supplied with each commercial 
> system are *heavily* patched. My Suse 9.2 system has a rpm for 
> glibc with fifty patches.  Fifty patches! 
> 
> Fifty patches which make the SuSE glibc binarily incompatible 
> with the redhat, and so on.  And everything is incompatible
> with the vanilla flavor.

I can sympathize with you.  I've spent several months
of my life building gcc and glibc.  (That's why I wrote
http://kegel.com/crosstool, so fewer people would ever have to go
through that hell.)

But fifty patches doesn't neccessarily mean binary incompatibility.
http://kegel.com/crosstool/crosstool-0.28-rc37/patches/glibc-2.3.2/
contains about 45 patches, but as far as I know, none of them
cause incompatibilities; most are neccessary to get glibc-2.3.2
to *build*.

It might be worth documenting at least one of the incompatibilities
you hint at.  What harm, in particular, have you found?
What use cases are involved?

Also, it's very much worth noting that LSB is designed to
eliminate a largish class of binary incompatibilities;
as time goes on, I expect it to actually be used for that purpose.
It might be the best way to solve the problems you're
thinking about (but I can't tell, since you haven't described
the real-world situation involved).
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html