Todd Vierling <tv@pobox.com> writes:

> 
> On 2 Jul 1999, Ian Dall wrote:
> 
> : > Hrm.  Thewn this is broken.  libgcc.a should most certainly be -fpic, as
> : > Cygnus compiles it that way.
> : 
> : There seems no simple way to get this into our build system. bsd.lib.mk
> : assumes that things with a .o extension are static and .so are dynamic.
> 
> Actually, the wauy is simple; adding ${CPICFLAGS} to the definition of COPTS
> used in the src/gnu/lib/libgcc/Makefile.  The build system doesn't care that
> they're PIC if they are going into a library named "libgcc.a".
> 
> I'll add an appropriate fix soon; however, given the type of change, it will
> probably be in line for 1.5 (and not 1.4.1).

Well, I tried this and it solved my immediate problem. However, when I
cam back to rebuild some of the statically linked executables (such as
"ps") ld complained about __DYNAMIC not being defined. I also
notice that --no-whole-archive seems to be a no-op.

      c++ -shared -Wl,--whole-archive libfoo.a -Wl,--no-whole-archive

produces a multiply defined symbol error for everything in libgcc.a.
This is all on the pc532 platform which still used the old ld.

Using -nostdlib has a problem in that the c++ startup file is left out
and constructors don't get called. However, it seems as though compiling
libgcc.a without -fpic and building shared libraries with

     c++ -shared -nodefaultlibs ...

might work for this platform. Apparently though in the elf case,
if there are dependant libraries this won't work.

We seem to be in the unfortunate position of not having an incantation
for building shared libraries which will work accross all ports.

Ian