On Wed, 2003-06-04 at 01:51, John Gay wrote: > >> This was my understanding as well. As I understand the situation, -fPIC > is > >> preferable to the non-PIC code which was there before. > > > >It's not quite that simple. This is about static libraries, which policy > >requires to be built without -fPIC. The problem arises when linking them > >into shared objects, for which there's xlibs-pic, like other -pic > >packages. > > > Ah! I see, Ted. (Do you really, Dougal? Uhm, No, not really.) > > Can you tell that I only know about PIC from a course in O/S's? I'd be > really interested in a proper explaination for this. > > I know that PIC code is 'supposed' to be better in that it can be loaded > into memory without regard to the actual location or layout. Why should > static libraries be built without -fPIC, and who's policy is it anyway?
Debian's. I guess the reason is that PIC code usually performs worse than non-PIC code (at least on weird architectures like i386) and that static libraries are usually linked directly into applications. > And why are static lib's being linked into shared objects? Because some shared libraries (or plugins, or whatever) use some X extension libraries which are only available in static form. But non-PIC code in a shared object is a bad idea, it (like so many things...) only works on i386 (and maybe some other architectures) by coincidence. On other architectures, this causes build or run time errors. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
