Re: fftw3 non-pic k7 optimisations
On Mon, Mar 07, 2005 at 07:05:40PM +0100, Marco d'Itri wrote:
> On Mar 07, Paul Brossier <piem@altern.org> wrote:
>
> > 10.2. Libraries
> > ---------------
> >
> > The shared version of a library must be compiled with `-fPIC', and the
> > static version must not be. In other words, each source unit (`*.c',
> > for example, for C files) will need to be compiled twice.
> >
> > hrm, but yeah of course, one could say that it's fine if a
> > library compiled with -fPIC still contains non position
> > independant code. :)
> It's still not generally acceptable, but the policy does not reflect
> current practice.
> The idea is that PIC code is acceptable on architectures which can
> support it (i386 and IIRC another one) *IF* there is a positive tradeoff
> between the speed gain and the wasted RAM.
> The most situation where non-PIC code is a good idea is a library
> containing hand-optimized assembly code. It may still be possible to
> rewrite it to be PIC without a major performance loss, but it would
> probably take a lot of time.
Marco, what's your current feeling towards #175077 (non-PIC code in
libdv) that you submitted back then when prelink entered Debian? It's a
case of hand-optimized assembly in a multimedia lib, and here I've
indeed tried (and failed miserably) to convert to position-independent
assembly. Should we keep such bugs open, waiting for policy to be
changed, downgrade them to wishlist, or simply close them unfixed?
Regards,
Daniel.
Reply to: