Re: A completely different approach to EH runtime

["David O'Brien" <obrien at FreeBSD dot org>]

On Wed, Feb 28, 2001 at 12:01:14PM -0800, Joe Buck wrote:
> > I have zero intention of supporting a shared libgcc in stock FreeBSD,
> > even with GCC 3.0.
...
> I understand and respect your caution, but I'd like to answer it by
> establishing policies that would enable the BSD and GNU/Linux distributors
> to use a shared libgcc with confidence.  The polcies would require the
> very controlled handling of version numbering and backward compatibility
> you refer to.

Actually *any* backwards in-compatible change will be a problem.  Since
libgcc.so is even lower-level than libc, as H.J. mentioned, *every*
binary and DSO will make reference to it.  Any backwards in-compatible in
libgcc.so that would require a version bump, would also force a version
bump in FreeBSD for /usr/lib/lib*.so and every shared lib that is part of
the Ports Collection.  This includes libgtk.so, libglib.so, KDE shared
libs, GNOME shared libs, etc...  Not only that, but our /usr/ports system
would have to have magic added to only bump the shared lib when building
on a system that has the newer libgcc.so.

Earlier this month FreeBSD wanted to change the traditional BSD stdio
__sF[] array (std{in,out,err} are defined in terms of this), so something
that was more modern and supported better mutex control (for
libpthreads).

Since *everything* uses libc, and the use of stdio is everywhere (and
unfortuneatly the interface so exposed), we hit the same problem.

A guarantee and policy could be crafted in total honestly and good faith
today, but I do wonder what will happen in the future when an
in-compatible might be required in libgcc.so.

I have many of the same concerns as H.J., except I think he is centering
too much on glibc, rather than the general problem of in-compatible
changes + DSO version number bumping in very low-level libs.


> If we don't convince you that we did it right, then of course you won't
...
> Without a shared libgcc, we have difficulties with handling exceptions in
> shared libraries.

A small test program+shlib showing how bad the problem can be would help
convince me that the gain is worth the potential pain.  At the moment, I
am not seeing any problems with exceptions in FreeBSD 5-CURRENT and GCC
2.95.2.  I do have a test system with an old 2.96 snapshot as its base
compiler, but I have not updated it in a very long time.

-- 
-- David  (obrien@FreeBSD.org)