This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
re: forestalling GNU incompatibility - proposal for binary relativedynamic linking
- From: Dan Kegel <dank at kegel dot com>
- To: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 24 Jan 2005 22:34:10 -0800
- Subject: re: forestalling GNU incompatibility - proposal for binary relativedynamic linking
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