Re: more non-PIC static libs in shared libs
On Fri, Jan 10, 2003 at 05:52:46PM +0100, Daniel Kobras wrote:
> On Fri, Jan 10, 2003 at 04:25:43PM +0100, Marco d'Itri wrote:
> > On Jan 10, Daniel Jacobowitz <dan@debian.org> wrote:
> >
> > >Actually, barring binutils bugs I thougt this was sufficient; I'd like
> > >to see an example of where it isn't (other than the current PPC linker
> > >bug).
> > When manually written (.S or inline) assembly code is linked.
> > See #175074 and 175077.
>
> Depends on what you mean by sufficient. It's sufficient if you want to
> assure the lib works.
This is only true on i386. Non-PIC PowerPC assembly in a shared
library will fail.
> It's not sufficient if you want to make sure that
> the lib can be prelinked. We need to decide whether we want to be able
> to prelink any lib, even those containing hand-crafted assembly code,
> even if it induces a preformance hit.
The performance gain of linking a library that has 10 symbols (I
exaggerate, I know) is minimal compared to allowing the library
to use the extra register if it a) can do it responsibly, and b)
causes the 20-30% increase in performance that was measured for
libmpeg2 by the maintainer.
Btw, this only applies to architectures that have full address
space branches and a very limited register set. I think i386
is the only one that fits this description.
Most of the problem relocations in libHermes could be fixed if
there was a way to resolve all the internal references in the
library at compile-linking time. The only way I've figured out
how to do this is to put everything in one .c file and declare
all internal functions as static. I am curious if there is an
easier way to do this that I have overlooked.
dave...
Reply to: