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

Re: Intend to create an -fPIC library package...

On Tue, Jul 21, 2009 at 04:52:52PM +0200, Wouter Verhelst wrote:
> > As I understand it, the performance drawbacks of a shared library are:

> > 1) The PIC code and its use of a GOT.  Given that we're talking about a
> >    PIC static library, this is not relevant.

> The argument was that a shared library is 'too slow'. Reading the
> discussion thread that Christian pointed to, it appears that Monty
> doesn't actually know what he's talking about, but read on some random
> IBM website that shared libraries are slower. Well, yes they are, but
> not by much, and the pain static libraries introduce outweighs that by
> much.

> Note also that shared libraries are only slower on x86 hardware due to
> the fact that they don't natively do PC-relative addressing, which needs
> to be emulated; x86_64 has dealt with this, and most other architecture
> (including m68k, for those following along at home) properly support it.

Yes, the *main* reason shared libraries are "too slow" is because they have
to be built with -fPIC, *and -fPIC is slow on i386*.

So building a _pic static library is pointless here, because it avoids all
the benefits of a shared library while bringing in the one drawback of
shared libraries that upstream appears to actually care about.

This should be maintained as a shared library instead.  Static libraries are
bad for security in general, and absolutely awful when they embed something
like a sql server.
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: