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: