This is the mail archive of the
mailing list for the GCC 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>, alan at lxorguk dot ukuu dot org dot uk
- Cc: gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com
- Date: Wed, 26 Jan 2005 13:15:49 -0800
- Subject: Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
- References: <41F5E862.email@example.com> <20050125195606.GA29787@venus> <41F72F7B.firstname.lastname@example.org>
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
> >First, the real world situation is that I compile my own programs,
> >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 (libselinux.so.1). 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.