This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Building libstdc++ non-shared with -fpic ?
- To: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Subject: Re: Building libstdc++ non-shared with -fpic ?
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Sat, 01 Jul 2000 17:09:30 +0100
- Cc: lundril at gmx dot net, gcc at gcc dot gnu dot org
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> > > Why do you require artificial limitations on the compilation system,
> > > when there is no technical reason to require them?
> >
> > Why are you assuming that the whole world is based on the ELF model of
> > linking? It doesn't work for a.out based shared libs or for HPUX SOM (or
> > whatever it's called in HPUX 10).
>
> It seems I was exaggerating. However, the original poster asked about
> his homegrown Linux system, on which indeed -fPIC is not required for
> shared libraries.
I sort of guessed that was probably going to be the case. But I've
learned from bitter experience that if you don't qualify statements like
that, you will be caught out somewhere along the line...
>
> > On a.out the linkers generally just get it wrong (since they can't
> > always tell non-pic code from pic code).
>
> See, generalising is difficult :-) On Linux a.out shared library
> system, the libraries where never compiled
> position-independent. Instead, they were linked to a fixed position.
Sounds pretty much like the old RISC iX model that Acorn used. But the
less said about that the better.
>
> I was just fighting the common misbelieve that shared libraries *must*
> be compiled with -fPIC.
In my experience it is safest to work with the rule "all shared libraries
must be compiled pic, but there are a few useful exceptions", rather than
"You don't have to bother about pic unless the tools force you too". You
are far less likely to be caught unawares with the first rule.
R.