Subject: Re: dlopen() and libgcc.a
To: None <M.Drochner@fz-juelich.de>
From: Nick Hudson <firstname.lastname@example.org>
Date: 12/09/2000 13:05:46
Matthias Drochner wrote:
> email@example.com 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
> > 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
aka firstname.lastname@example.org, email@example.com