Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking

[Edward Peschko <esp5 at pge dot 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..
)