Subject: Re: dlopen() and libgcc.a
To: Nick Hudson <nick@nthcliff.demon.co.uk>
From: Todd Vierling <tv@wasabisystems.com>
List: tech-toolchain
Date: 12/10/2000 10:47:08
On Sun, 10 Dec 2000, Nick Hudson wrote:
: > You're thinking of mixing -fpic and -fPIC, which does not work on sparc.
: > If libgcc is compiled -fPIC, it can be linked with a standard non-PIC
: > executable just fine.
:
: Doh! I was getting these mixed up again! What about a non-PIC libgcc in
: a shared library though? - this must be a no-no. This would also explain
: Charles' change to LIBGCC_SPEC.
You can do that, but you'll get RSS text relocations -- in other words, the
runtime linker will have to do part of the compile-time linker's job.
: > I'm considering adding a PIC version of libgcc as a shared object, since
: > that's already done by gcc 2.95.x+. That doesn't have the -fpic/-fPIC
: > problem (it's a separate .so) and will get pulled in automatically only for
: > "cc -shared".
:
: Isn't this a fairly easy change to src/gnu/libgcc/Makefile and
: LIBGCC_SPEC? I'm convinced I need this for the KDE2 pkgs I've been
: working on to work correctly as they require C++ exception handling in
: shared objects.
This is already done for some targets, IIRC. I'll have to check.
However, my changes will be *only* to the NetBSD (BSD-style) Makefiles.
--
-- Todd Vierling <tv@wasabisystems.com> * http://www.wasabisystems.com/
-- Speed, stability, security, and support. Wasabi NetBSD: Run with it.