This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Tue, Jan 25, 2005 at 09:49:47PM -0800, Dan Kegel wrote:

> Edward Peschko wrote:
> >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. 
> Why are you replacing the system glibc?  That's never a good idea.

I'm not replacing the system glibc - all I am doing is making the point
that *if* you compile glibc and run it against system binaries, the 
system binaries break.

With the same version of gcc, and glibc even - *without* the patches
that SuSE supplies. 

Hence, the system glibc and vanilla glibc are binarily incompatible. If the
LSB's goal is to prevent this, it isn't working - at least not in this
simple experiment.

> >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.
> There's the problem: you're trying to distribute a copy of
> glibc.  Don't do that.  Glibc is an integral part of the system.

I'm not trying to 'distribute it'; I'm trying to make a vanilla version.
If I need to go from system to system and compile glibc for that system, I'll 
do so. I just want the freedom to build everything from source control.

All this started because I needed to change some system headers for files
distributed by glibc. I don't have exclusive rights on the machine, nor do 
I have root on the machine. And I don't want to make the hack of copying 
just modified headers. I'd rather keep everything clean and separate - the best 
way to do this would be to compile my own distribution, which I attempted to do.
I suggested the 'rpath-like' functionality in the LD_LIBRARY_PATH as a way
to have two glibcs coexist on the machine.

If your argument is that building glibc isn't for the faint of heart
and should be left to the experts, my question is why? *Why* should it be left
for the experts, and why should it be a black art? Isn't it the fact that it 
is a black art retard its advancement, and make progress go slower? Isn't 
it the fact that it makes systems stuck in the mud because they can't 
easily experiment with it?

I'm not trying to be inflammatory here, I'm just noting what I see, and the
results of my experiment; I can't think of one good reason why building a 
glibc should be so difficult.

And surely there should be a method to build a separate glibc *outside 
the system glibc* - if anything to make sure that the developer 
doesn't trash his system unintentionally in playing around with it. And 
glibc just might be as fragile as it is because it doesn't get enough
hands experimenting with it.


    ps - for those who are saying the LSB is the only answer, here's 
    another experiment. I just took the 'ls' executable from my SuSE 
    machine (2.4.18) and tried to run it on a Fedora box (2.4.21-27). 
    I got a 'missing library ( Seeing SElinux wasn't 
    installed on that machine, I transferred it over, and got a 
    'no versioning info' error from libacl, and finally a segfault.

    Now, if 'ls' doesn't have a chance of being cross-distribution
    compatible, what chance do other, more complicated programs have?

    If I understand the LSB right - that it is a bunch of policies that
    vendors are meant to follow but don't *have* to follow in putting
    together their distributions, and that programmers have to follow
    in writing them (and if they don't do so things will break in 
    mysterious ways), well then its chances of true success are fairly
    slim.  It forces developers to have multiple distribs handy *just
    to be sure* their apps will run on all of them. 

    pps - admittedly I could be reading the LSB's intent wrong. 
    Feel free to correct me.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]