* Trent W. Buck | 2009-03-21 21:38:14 [+1100]: >>From IRC: > >kalikiana> Regarding -fPIC, I don't really see how I could avoid it. >kalikiana> If somebody finds it wrong, I would really like to know an >kalikiana> alternative because it is needed for linking extensions. > >twb> I looked at the Debian Policy manual again, and it says -fPIC >twb> *must* be used for libraries. ...which I assume also means >twb> extensions. But I don't know if -fPIC is supposed to also be >twb> used for apps themselves? I think maybe the guy I was talking to >twb> on #debian-mentors was confused, and meant you need a reason to >twb> *not* use -fPIC. > >kalikiana> I also have a reason to not use it actually, which is that >kalikiana> for instance on x86-32 it makes the application slower. > >twb> OK, Debian says that reason is not good enough for Debian. >twb> http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries >twb> So for Debian I will just enable it always. Sorry for the >twb> confusion, I just haven't dealt with libraries before and I >twb> didn't understand any of the issues.
The problem here is that it is not just a library. libkatze itself is a .a static library which is merged into midori and this is fine. But it is also merged into a few add-ons which are .so and that's where you need the -fPIC because now the static library becomes suddenly a shared library as well. Adding -fPIC to the whole build process is a bad idea please don't do that. My initial proposals where: - make libkatze a .so. midori and extension can link against that. => that one was NAKed by upstream because a new lib is not what he had in mind if I remember correctly. - add fPIC unconditional and use it while build ing libkatze (not always). => was NAKed by upstream because it is so much slower on x86_32. Now, we need special care for parisc and mips afaik. Other arches may follow once the offset are big enough. Maybe we could go the other way around and add -fPIC to libkatze unless it is x86_32? Sebastian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
