Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

> Have you read
> 
> http://gcc.gnu.org/ml/gcc/2001-02/msg01022.html

Yes, I just didn't find it very convincing.

> Am I wasting my time here?

Well, you're proposing a way of doing things that is different
from how such problems are traditionally solved in GNU/Linux,
and I don't think that this special handling is necessary.

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

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

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.