Re: A completely different approach to EH runtime

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

On Wed, Feb 21, 2001 at 05:37:47PM -0800, Per Bothner wrote:
> "H . J . Lu" <hjl@valinux.com> writes:
> 
> > Say I build a DSO, libfoo.so, with $prefix/bin/gcc. And I do
> > 
> > 	handle = dlopen ("libfoo.so", ...);
> > 
> > from an executable, bar, built by /usr/bin/gcc. When I start bar,
> > /lib/libgcc_s.so is loaded into memory. Now when dlopen comes, which
> > libgcc_s.so should be used by libfoo.so? Since bar has already loaded
> > libgcc_s.so from /lib, it won't load $prefix/lib/libgcc_s.so. Now
> > libfoo.so is very upset unless /lib/libgcc_s.so is 100% compatible
> > with $prefix/lib/libgcc_s.so.
> 
> Yes, indeed.  But why are you worrying about this case?
> 
> There are two cases:
> (1) /lib/libgcc_s.so is compatible with $prefix/lib/libgcc_s.so,
> so no problem.  (This is of course what we're hoping for!)
> (2) /lib/libgcc_s.so is not compatible with $prefix/lib/libgcc_s.so.
> In that case, the problem is using /usr/bin/gcc to compile bar which
> is using a library compiled by an incompatible compiler.  Well, don't
> do that!

/lib/libgcc_s.so is not compatible with $prefix/lib/libgcc_s.so. But
$prefix/lib/libgcc_s.so should be compatible with /lib/libgcc_s.so.
Otherwise, they will have different sonames. The point I want to make
is you cannot have 2 shared libgcc_s.so visible to ld.so at the same
time unless you know what you are doing.

> 
> In other words:  This is not a problem for distributors, it is
> not a problem for developers using the pre-installed gcc in /usr/bin,
> it is not a problem either you or the gcc maintainers should worry about.

I disagree.

Here is my suggestion which may or may not be a good one :-).

1. Add a hook to libgcc.so so that we can query which version of
ABI it supports.
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.

Now it leaves a case where /lib/libgcc_s.so doesn't support the
interface the new gcc needs. I don't think shared libgcc should
be enabled by default. A separate configure option may be added.

In any event, whatever we come up with has to be acceptable to both
gcc and glibc people.


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