This is the mail archive of the gcc@gcc.gnu.org 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]

Re: A completely different approach to EH runtime


HJ writes:
> > > 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?

I wrote:

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

HJ replies:
> 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.

Ah.  Well, you then have an even better solution: when you install your
alternate, older version of gcc, don't set LD_LIBRARY_PATH.  You get
the new library and everything works (for your C programs; for C++ it's
another matter, but that's not new).  But a developer who works on
an important shared library and who doesn't like LD_LIBRARY_PATH is
crippling himself.

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

You claim that your experience with glibc development gives you unique
insights into these problems, but you refuse to share this experience
in detail.  Instead, your attitude is "trust me, I'm an expert".

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

Well, it's still been useful that you raised these issues.



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