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. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
