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


On Thu, Feb 22, 2001 at 10:42:19AM -0800, Joe Buck wrote:
> 
> > 1. Add a hook to libgcc.so so that we can query which version of ABI it supports.
> 
> I'm not sure that this is really needed, as the problem can be solved in
> a simpler way.  But it doesn't hurt to have such a hook.  It seems the
> only improvements come about for users trying to put an older libgcc_s
> on a box with a newer one installed as the system compiler, which is
> a case I give vastly less priority to, especially since there is a simpler
> solution (just nuke the private libgcc_s after installation).

The user has to know to do that. It is not a problem for me.
But I am not sure about a random Linux user.

> 
> > 2. By default, under Linux, the shared libgcc is enabled only if 
>  
> >   a. --prefix=/usr or --with-slib-dir=/lib is passed to configure. It
> >  tells gcc that we want to configure it as the system compiler. Or
> >  b. /lib/libgcc_s.so support the interface we need. In that case,  
> >  gcc just uses /lib/libgcc_s.so instead its own. Or
> >  c. There is no /lib/libgcc_s.so at all. This case I am not very sure
> >  since some bad things may happen when the system vender provides  
> >  /lib/libgcc_s.so later. You may wind up with 2 shared libgcc_s.so.
> 
> The problem with this is that you are trying to move packaging jobs into
> gcc's build process, because you fear that system vendors may make
> mistakes.  We cannot expect "make install" to do all of the work that
> a distribution provider will need.

"make install" is just very small part of packaging. At least, it
is the case on RedHat. It is for consistency across different
Linux distributions. Also it is for normal users.

> 
> I think that the way to solve this is that we come up with a list of
> gotchas and recommendations: what to do when installing a compiler with
> an older or newer libgcc_s.so.  I think that the problem can be solved
> with methodology rather than code.

I can work it out without any methodology or code from gcc. I don't
think a methodology will work for average Linux uers. Please keep
in mind libgcc_s.so is now a system library.



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


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