Subject: Re: different behaviour of system cc and TOOLDIR/cc
To: Jason Thorpe <thorpej@wasabisystems.com>
From: Matthias Drochner <M.Drochner@fz-juelich.de>
List: tech-toolchain
Date: 06/11/2003 18:02:44
thorpej@wasabisystems.com said:
> it does not account for the possibility of the GCC-provided crtbegin/
> crtend being in a different location from ${DESTDIR}/usr/lib (like,
> say, if you're compiling the system with GCC 3.3)
I've built gcc-3.3 from pkgsrc, and didn't get any crt* files.
What's the correct way to setup a gcc3 to build the tree?
To my disappointment, after having the bsd.lib.mk in an
"almost ready" state, I found that the problem I started
all this for isn't solved:
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:
"%{!shared:%{!symbolic:-lgcc}}"
in the !NETBSD_NATIVE case.
Why is the pic/non-pic thing not done here?
Btw, the pkgsrc gcc-3.3 builds only one libgcc, containing
non-pic code.
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
programs.
best regards
Matthias