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: <rearnsha at arm dot com>, "Alexandre Oliva" <aoliva at redhat dot com>
- Subject: Re: Building libstdc++ non-shared with -fpic ?
- From: "Scott Bambrough" <scottb at netwinder dot org>
- Date: Tue, 4 Jul 2000 20:04:57 -0400
- Cc: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>, <lundril at gmx dot net>, <gcc at gcc dot gnu dot org>, <rearnsha at arm dot com>
- References: <200007030847.JAA10695@cam-mail2.cambridge.arm.com>
> > On Jul 1, 2000, Richard Earnshaw <rearnsha@arm.com> wrote:
> >
> > >> > That would imply that you are able to build shared libraries, which
> > >> > use code which is not position independent
> > >>
> > >> That is indeed the case.
> >
> > > But only if your object model supports it.
> >
> > Not only the object model. The dynamic loader must support it too. I
> > remember a case of someone building shared libraries out of non-PIC
> > code on GNU/Linux/ARM (what a coincidence :-) that would fail because
> > glibc's ld.so wouldn't handle a particular kind of relocation.
>
> Indeed. This 'bug' was the first time I'd ever heard of non-pic code
> going into a shared library. I guess it must have been the same for
> whoever implemented that code on the ARM.
>
That would be me. And this particular "feature" of ELF is poorly
documented, and IMHO a poor design choice. It assumes the underlying
architecture can branch anywhere in the address space. It is still a
problem in the dynamic linker on ARM systems.
Scott