Re: A completely different approach to EH runtime

["H . J . Lu" <hjl at valinux dot com>]

On Thu, Feb 22, 2001 at 10:19:45AM -0800, Joe Buck wrote:
> 
> Here's one possibility: GNU/Linux distributors put libgcc_s.so in its
> own package, and specify that a program built with 3.0.x depends on
> libgcc_s version 3.0 and with 3.1 we depend on 3.1.  This Depends:
> argument only needs to be changes when there is a backward-compatible
> but not forward-compatible change.  When a user attempts to install
> the new ls as you suggest, apt-get or Red Carpet or whatever

I was not talking about a user installed a new ls.

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? She/he
now has to unset LD_LIBRARY_PATH. When he/she installs, gcc 3.2, he/she
has to set LD_LIBRARY_PATH again. What if he/she has a NFS mounted
home directory, he/she installs gcc under $HOME/gcc-3.x and he/she
logs on different Linux machines which have gcc 3.0, 3.01, 3.1 as
system compilers?

> will automatically get the new libgcc_s package.

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.  

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.

> 
> > > People should be able to test gcc on machines where they don't have root.
> > 
> > Isn't that the same problem to test glibc? As I said before, having the
> > shared libgcc under Linux puts libgcc in the same category as glibc. Do
> > you really think you have seen something new with shared libgcc we
> > haven't seen in glibc before?
> 
> 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.

> 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.


-- 
H.J. Lu (hjl@valinux.com)