Subject: Re: different behaviour of system cc and TOOLDIR/cc
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: Todd Vierling <firstname.lastname@example.org>
Date: 06/11/2003 12:20:10
On Wed, 11 Jun 2003, Matthias Drochner wrote:
: I wanted a shared object build to automatically link in
: a PIC libgcc.
: The cross-gcc doesn't even try, due to the spec definition:
: in the !NETBSD_NATIVE case.
Probably should be fixed, now that gcc3 builds a shared libgcc (see below).
: Btw, the pkgsrc gcc-3.3 builds only one libgcc, containing
: non-pic code.
Actually, it should be building a libgcc_s.so -- that's what other gcc
targets are using for ths purpose. (It's PIC, but in the form of a linked
I don't know if libgcc_pic.a is generated along the way to this .so,
however, or if it can be installed automagically.
: For comparision I looked at a Debian system - there is just one
: libgcc.a which is always used (the spec rule is just "-lgcc"),
: but libgcc.a contains PIC code. (checked with objdump -r)
: Seems correct, albeit not optimized for performance of static
Which is a possibility, but there have been problems linking PIC and non-PIC
on some architectures in the past. I don't know if that is still the case.
-- Todd Vierling <email@example.com>