Re: Building libstdc++ non-shared with -fpic ?

[Richard Earnshaw <rearnsha at arm dot com>]

> > 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.

> > so why would it be necessary at all to use the -fPIC compiler switch
> > to create a shared library ?
> 
> It is not necessary. However, if it is not done, the dynamic linker
> will have to relocate the library at load time. As a result, the
> start-up time will increase, as will the memory consumption, since the
> shared library won't be shared across processes.

So it isn't really a shared library, just a dynamically linked one.

> On some systems, it used to be that the dynamic linker refuses to do
> any relocations. However, these systems are broken, and have been all
> corrected, AFAIK.

Nope.

> 
> > (Why should it be possible that some of the code has do be PIC and
> >  some of it doesn't need to be PIC ? 
> 
> I don't know whether it *should be* possible - I know it is.

Wrong (in the global case).

> 
> If you are willing to accept this, some useful cases come to mind. It
> is know possible to link a static library into a shared library, even
> if that library was not compiled with -fPIC, and even if you can't
> recompile the library.
> 
> >  I think the all or nothing principle should apply:
> >  All PIC -> shared library possible
> >  Not all PIC -> shared library impossible
> 
> 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).  On a.out the linkers generally just get 
it wrong (since they can't always tell non-pic code from pic code).  On 
HPUX the linkers just barf and won't let you put non-pic code in a shared 
library (even more bizarrely, they won't let you put pic code in the main 
part of the executable).


Richard.