[CMake] faq update?

[Goswin von Brederlow]

"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