[CMake] faq update?

[Olivier Delannoy]

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 <brederlo at informatik.uni-tuebingen.de> wrote:
> "Sanchez, Juan" <juan.sanchez at amd.com> 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
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>


-- 
Olivier Delannoy
ATER
PRiSM Laboratory
Versailles University, FRANCE