mathieu: I have read that great article
How to write shared libraries from Ulrich Drepper. I was quite enthusiastic - seems like there's a thousand things everyone writing a shared library should know, but I had never seen these written up anywhere. Great stuff.
In particular, I was very interested by Ulrich's comments about -fPIC code. I've heard a thousand persons before him tell me that the -fPIC overhead is negligible, blah blah blah. Well it's not in my experience - in libmpeg2 the -fPIC overhead is about 8% (on an athlon CPU). To me, negligible is defined as being below 1%. But, the very interesting thing I learnt from Ulrich's paper is that if you use gcc's visibility attribute so your library's internal symbols do not get exported, gcc (>= 3.1) can use that knowledge to avoid generating PIC code. Supposedly this should get rid of most of the -fPIC overheads.
So I was very excited to try it. But all I got out of it was a gcc warning: `visibility' attribute directive ignored. Even Ulrich's own C example gives me the same error. And it still generates PIC code for places where it should not have to.
Now I feel cheated... The whole PIC infrastructure is a huge mess. libtool also has a -prefer-non-pic option for those who want to avoid the PIC overhead on architectures that can tolerate this... but the damn option is broken, it still tries to generate non-pic code on some of the architectures that dont tolerate it... It's not even difficult to test for, it's a 20 line autoconf macro, but why use libtool and why does it have a -prefer-non-pic option if you're still required to worry about architecture specificities...