Re: A completely different approach to EH runtime

[Jonathan Lennox <lennox at cs dot columbia dot edu>]

> OK, glibc people, consider yourselves asked.  However, I *also* would like
> to hear from maintainers of the C library on BSD systems as to what
> problems *they* forsee (since they would also have a shared libgcc to deal
> with).  There is nothing special about glibc here, though the glibc people
> do have lots of valuable experience with symbol versioning and the like.

I'm not a BSD maintainer, but I am a BSD *user*, and I'm wondering about the
following scenario.

Sometime in mid-2002, I'm running FreeBSD 5.0-STABLE, which has gcc 3.0.4 as
its system compiler, and libgcc_s.so installed in /usr/lib alongside
libc.so.  (On FreeBSD all of /sbin and most of /bin is linked statically, so
this isn't a boot-time problem.)

The gcc team releases gcc 3.1.  I think "oh, cool" and decide to install it
in /usr/local/ -- I want to be able to play with it, but I naturally don't
want to clobber my system compiler.  I'm not too worried about shared
library search paths, because FreeBSD's dynamic linker includes
/usr/local/lib/ in its search path.

Now, assume that gcc 3.1 has had IA64-style exception handling added.
libgcc_s in 3.1 is completely backward-compatible with the one in 3.0, but
it also has the _Unwind_* ABI functions defined.

I compile an exception-handling-using C++ program.  It links with
libstdc++.so and libgcc_s.so.  I try to run it, and get:

/usr/libexec/ld-elf.so.1: ./foo: Undefined symbol "_Unwind_RaiseException"

because ld-elf.so's search path includes /usr/lib before /usr/local/lib, and
so dynamically linked in the gcc 3.0 version of libgcc_s.so.

Now, there are ways around this, probably involving -rpath, but I don't
think any of them are particularly pretty.  (And I wouldn't expect a Random
Naive User who just wants to experiment with the latest version of gcc to be
able to figure out what they should be.)

Am I misunderstanding something?  Would bumping the shared library version
number of libgcc_s.so fix this without breaking other things?  (I naturally
*don't* want gcc 3.1's libgcc_s.so to be linked in for programs that
*weren't* compiled with gcc 3.1 -- imagine if this isn't actually the
released version of gcc 3.1, but rather development snapshot...)

Alternately, what happens in this case given Zack's solution (assuming a
workaround can be found for the DSO problem)?

I don't want to take a strong stance in this flame war, but I don't think
my scenario would be terribly unusual, and it's important at least to have
simple instructions as to how to make this work.

-- 
Jonathan Lennox
lennox@cs.columbia.edu