Todd Vierling wrote:
> 
> On Sat, 9 Dec 2000, Nick Hudson wrote:
> 
> : > Yes, I've noticed this too. Perhaps there are reasons - parts of it
> : > needed in early startup? Is there a problem with libgcc linked in
> : > statically? Is it supposed to make a difference from the symbol
> : > scope POV?
> :
> : Mixing PIC and non-PIC seems to cause problems only on some
> : architectures, eg. sparc see PR/8669.
> 
> 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.

> 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.

I'd really like to put this one to bed as its driving me mad.

Nick
-- 
aka skrll@netbsd.org, skrll@excite.co.uk