Re: A completely different approach to EH runtime

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

On Thu, Feb 22, 2001 at 01:38:01PM -0800, Joe Buck wrote:
> 
> > 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 have a few problems with it:

1. The symptom may not be that obvious. Install a new gcc shouldn't
affect the way system binaries work.
2. I don't like LD_LIBRARY_PATH at all.

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

Why do I have to explain to you how we develop glibc? After all, it
is a system library. The normal user just expects it works.

BTW, it is my last email on this topic. Ultimately, I am not the
person you should sell shared libgcc to. I just hope at the end of
the day everything will be turned out fine.


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