Re: Reason for 10.2 -fPIC requirement
On Sun, Sep 18, 2005 at 06:07:25PM +0200, Marco d'Itri wrote:
> Having non-PIC shared libraries is not generally acceptable, but
> policy does not reflect the current practice.
> Shared non-relocatable code is acceptable on the few architectures which
> can support it (i386 and maybe another one) only when there is a
> positive tradeoff between the speed gained and the RAM wasted.
> The most common situation where a non-PIC shared library is a good idea
> is when it contains hand-optimized assembly code. It may still be
> possible to rewrite it to be relocatable without a major performance
> loss, but it would probably take a lot of time. And again, very few
> architectures support non-PIC shared libraries at all: on most they
> would just not work.
My understanding is that policy require to compile with -fPIC, but not
that the resulting library be PIC, which cover the case above.
(And also require that the library build/link correctly which cover the
few architectures where PIC code is mandatory (hppa,ia64,alpha,arm,x86_64)).
When compiling with -fPIC most of the code will be relocatable so there
should not be too much RAM wasted.
Also note that i386 is a platform from the remaining set where the PIC
penalty is specially high, so we might decide to be laxer for
computationaly intensive packages. Anyway that should be handled in a
case by case basis.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: