I have not yet contributed to the wiki or anything to CMake yet so I might not be in position to give advice, but if I look at the main page for CMake on the wiki I can see a page named Platform Dependent Issues. I don't think the faq is a good place for platform specific stuff or stuff which work on only a few compiler. A page like Platform Tips and Trick or something like this might be best suited and the faq can contains a link to related trick.
I am more or less in favor of keeping the faq as independent of the platform as possible. Yet the trick is good and usefull !!! On 9/14/07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > "Sanchez, Juan" <[EMAIL PROTECTED]> writes: > > > Hi, > > I was aware that fPIC induces a performance penalty, but I didn't realize it > > was bad as you mention (30% degradation). My preference is not reusing the > > Some people claim 30% penaltiy. This number is obviously highly > dependant on the code and architecture. For example a library for > fractals will spend 99.99% of its time in a inner loop without any > non local jumps and only use local variables. PIC or not PIC will make > no difference there. > > > object files for static and dynamic libraries, but I am working with people > > who do. I think your three variant system is attractive (.so .pic.a .a). > > The secret is: > > Some people worry about disk space. > > You can use the same objects for .so and _pic.a. Think of _pic.a as a > temporary libarry that will be merged into the *.so in the end. Like > when you create a libfoo/subdir1.a, libfoo/subdir2.a and merge them > into libfoo.so. But you install the _pic.a from one source and some > other source links it in later. > > > The shared library is for other packages depending on these library > > functions. > > The static library is so binaries in the package can link. The rpath is not > > known at compile time. It is only known when our internal release system is > > done. Some people don't want a wrapper script setting the LD_LIBRARY_PATH. > > Others don't want to hack the binary to encode the proper rpath after the > > fact. > > Don't worry, this code is for internal use only. > > Regards, > > Juan > > In general I would say forget about *.a files. They waste time to > compile, disk space to store and memory to run. > > I don't think you will see those claimed 30% penaltiy unless you > specifically construct a case for it. So why not use the shared > library for binaries from the same source too? That way they are > smaller and share the library when run. > > As for LD_LIBRARY_PATH and rpath I don't see where that comes into > play. If you build a public shared library for use with other sources > then put it in a public place, one in the default search path. AND > DON'T SET AN RPATH. Setting an rpath for a library means it won't be > found if it resides at a different location than during build and > can't be overridden with LD_LIBRARY_PATH. Say you had > /usr/lib/libfoo.so during compile but now you want to test a new > libfoo in ~/src/libfoo/lib/libfoo.so. With rpath set you have to > recompile. Without you set the LD_LIBRARY_PATH to look there first. Or > you had /usr/local/lib/libfoo.so but now libfoo was packages and you > installed the debian package and have /usr/lib/libfoo.so. Do you want > to have to recompile all your software that uses libfoo? > > The only valid use of rpath I see is for non public shared > libraries. Often that spells plugin and you would have an rpath of > /usr/[local/]lib/package/plugin.so for it. Although I prefer to have a > config file listing plugin locations and have the software search at > runtime. Other times you have some shared libraries that aren't for > public use but shared between several binaries from your source. Then > an rpath of /usr/[local/]lib/ is acceptable. As I'm new to cmake I > don't know how it handles those. You probably know better. > > MfG > Goswin > _______________________________________________ > CMake mailing list > [email protected] > http://www.cmake.org/mailman/listinfo/cmake > -- Olivier Delannoy ATER PRiSM Laboratory Versailles University, FRANCE _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
