Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

HJ writes:
> I was not talking about a user installed a new ls.

Um,  I directly used the example you gave and showed it would be solved.
If you think I solved the wrong problem, then you'll need to write more
clearly.

> 1. The system gcc is gcc 3.0.
> 2. A user installed a new gcc, 3.1, with libgcc_s.so in $prefix/lib.
> 3. User sets LD_LIBRARY_PATH to $prefix/lib.
> 4. The system is upgraded to gcc 3.2.
>
> Now what happens to the user? Which libgcc_s.so will he/she get?

The user will get the libgcc_s.so that is pointed to by LD_LIBRARY_PATH.
This will be the one from 3.1.  Now, if there is some program that
is installed by the upgrade that needs a symbol that is defined in
the 3.2 libgcc_s.so, but not in the 3.1 libgcc_s.so, that program will
fail to start -- the dynamic link will have an unresolved symbol.
This is the problem you are worried about, right?  Read on.

> She/he now has to unset LD_LIBRARY_PATH.

That's one choice, but there is another, better solution.  Simply delete
$prefix/lib/libgcc_s.so!  Since the system version is newer, the 3.2
version will provide all of the functionality required by 3.1.  A user
isn't going to want the older compiler for the purpose of getting the
older libgcc_s.so.

People may encounter this if we have to add a new interface.  Solution:
put it in the FAQ.

> I never doubt GNU/Linux distributors can find a way to fix the libgcc
> mess. But if it is not supported by gcc itself,
> 
> 1. Each distributor may a different scheme.
> 2. A normal Linux user may find it is evry confusing since she/he may
> not just ftp a new gcc from ftp.gnu.org, untar, configure, build,
> install and expect the new gcc will work safely.  

First off, you are overstating the mess.  The "scheme" is simple:
put libgcc_s.so in /lib.  Flag packages as depending on this library.
THE END.

And new gcc's WILL work safely.  Only OLD gcc's (older than the system
compiler) might have a problem.

So: we should prepare a document describing the recommended way to avoid
the problem.  It's not hard; it amounts to the following points:

* If you have more than one gcc that uses libgcc_s.so on your system, it
is OK if the older version is the "system" libgcc_s.so (i.e. the one
installed in /lib).  If you want to run a non-system gcc that is *older*
than the system libgcc_s.so, you should remove $prefix/lib/libgcc_s.so.
This means that everything will use the newest version of libgcc_s.so
on the system.

* On systems with package management, treat dependence on libgcc_s.so
as a dependency like any other.

> Now we go back to gcc 2.7.2.3 again. What I'd like to see is a
> GNU/Linux distributor can just do
> 
> # ./configure --prefix=/usr
> 
> and everything will be handled correctly just like glibc so that a
> system compiler, gcc 3.0, works exactly the same on RedHat, SuSE, ....
> Also a user should be able to safely build/install a different version
> of gcc, just like another piece of third party software.

Your 2.7.2.3 approach was, IMHO, broken.  It made it harder, not easier,
to have multiple gcc's on one box, since energy was concentrated on
making the --prefix=/usr case work at the expense of making the other
case work.  It was extremely dangerous as well: GNU tools install in
/usr/local by default.  Your 2.7.2.3 defaulted to /usr, meaning that
an unaware person could wipe out his/her system gcc with configure,
make, make install because she expected to wind up with a new gcc in
/usr/local/bin, not /usr/bin.

--prefix=/usr should not be magic.  Now I'd be willing to have another
flag that says to install libgcc_s in a different directory.  But it
should be explicit.

> > Yes, there are similar problems, but libgcc_s is a vastly smaller library,
> > therefore the problems are manageable.  Surely you are not claiming that
> 
> It doesn't matter. You still have to deal with them.

I think that I've outlined how to deal with the problems and you haven't
convinced me that there is anything insurmountable.

> > you are not capable of testing a a new glibc on a box with an old glibc
> > installed?
> 
> Have you tried to change/test glibc? "make check" in glibc makes sure
> glibc is basically sound. I also do a few test runs with some tricks.
> I can switch back to a known good one if test runs fail. But still
> testing glibc on a live machine can be very tricky.

If you can't make the two glibc's coexist, there is something wrong.  If
the newer glibc is truly backward-compatible, then everything should just
work if it is first in LD_LIBRARY_PATH, at least for non setuid programs.
And the setuid programs should continue to link against the system library.

It should be possible to do glibc development on a machine that you don't
have root access to.  If it isn't, the problem is attributable to bugs
either in glibc or the dynamic linker.  The BSD libc people aren't having
the kinds of difficulties you are reporting.