Subject: Re: dlopen() and libgcc.a
To: None <M.Drochner@fz-juelich.de>
From: Nick Hudson <nick@nthcliff.demon.co.uk>
List: tech-toolchain
Date: 12/09/2000 13:05:46
Matthias Drochner wrote:
> 
> nick@nthcliff.demon.co.uk said:
> > I would agree that linking in libgcc is the right thing to do.
> > However, libgcc is not available as a shared library or even compiled
> > -fPIC.
> 
> 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. 

> > LIBGCC_SPEC was changed by Charles recently to specificaly not include
> > libgcc.a when gcc is invoked with -shared
> 
> Ah yes, and pulled up, as a bugfix for mozilla on ppc.
> Isn't there -nostdlibs if one wants the standard libs to be left out?
> With c++, libstdc++ is still linked in regardless of -static, so this
> looks more like a hack.

Well not according to the gcc documentation. 

The information I've collected on this subject was summarised in 

http://mail-index.netbsd.org/tech-toolchain/2000/09/13/0000.html

 
> > There seems to be some magic used by Linux systems that
> > I don't understand.
> 
> The mandrake distribution I tried does only have a static libgcc.a,
> as we do. So the example I quoted in my last mail will link in these
> runtime functions statically into the object to be loaded.

The suse_* packages, for example, have a /emul/linux/usr/lib/gcc-lib
directory that includes a libgcc.map file that is included in the
LIBSPEC. This is the stuff I was referring to when I said "stuff I don't
understand".

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