[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: