This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
- From: Edward Peschko <esp5 at pge dot com>
- To: Dan Kegel <dank at kegel dot com>
- Cc: gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com
- Date: Tue, 25 Jan 2005 11:56:06 -0800
- Subject: Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
- References: <41F5E862.2030906@kegel.com>
On Mon, Jan 24, 2005 at 10:34:10PM -0800, Dan Kegel wrote:
> 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*.
Well, that might be the case with your fifty patches, but it sure
isn't the case with mine..
I build glibc out of the box, ie: no patches on a SuSE machine, same
version as the OS (glibc-2.3.3), using latest gcc(gcc-3.4.3)
get segmentation faults every time when I try to run it against
system binaries. I set LD_LIBRARY_PATH back, and the segfaults go away.
> 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
First, the real world situation is that I compile my own programs, libraries,
etc - sort of a 'distribution within a distribution' which I maintain
and make portable to win32,solaris,linux,os390, etc. I don't need
root because I can configure the prefix, and everything is run out
of source control. I can also control environments and migrate
executables from one environment to the next (dev -- test -- prod)
after they go through enough testing. This setup allows me to
version in new binaries very easily, because I can test them
simultaneously, and promote them when they are ready.. and thie problem
arose when I tried to add glibc to the list of packages I support.
Second - as far as the LSB standard is concerned, migrating to it
from incompatible glibc's is a trick in itself; you need to support
the legacy applications whilst you are migrating.
And hence to facilitate supporting the LSB it makes a lot of sense
to be able to support 2 incompatible libcs on the same machine at the
same time.
But there doesn't seem to be a good way to do this. The best solution
someone has come up with so far is run stuff chrooted, which isn't
really a solution at all, because it doesn't allow for interoperability.
So - there is work being done to be able to swap between two kernels,
why not two glibcs? I'm open to other ideas aside from mine..
Ed
(
ps - as far as "* == path to binary" suggestion is concerned, the
one potential drawback that was mentioned was that binaries that didn't
match "/bin/?$" as a regex would be vulnerable if they picked up ../lib
inadvertently.
I'm trying to think of a case where this is true..
)