This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A completely different approach to EH runtime
On Wed, Feb 21, 2001 at 05:22:41PM -0500, Jonathan Lennox wrote:
> I'm not a BSD maintainer, but I am a BSD *user*, and I'm wondering about the
> following scenario.
...
> 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.
Will not be a problem unless the SONAME's are the same. In FreeBSD, it
isn't libgcc_s.so that is burned into a binary, but libgcc_s.so.1 (for
example). The lib*.so symlink is only for convenience of the linker
command execution. But this does bring up the point of having to be
*very* careful about shared lib versioning (name) when a 3rd party lib
matches the same base name as a stock library.
--
-- David (obrien@FreeBSD.org)