<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [CMake] faq update?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Hi,<BR>
<BR>
I was aware that fPIC induces a performance penalty, but I didn't realize it was bad as you mention (30% degradation).&nbsp; My preference is not reusing the object files for static and dynamic libraries, but I am working with people who do.&nbsp; I think your three variant system is attractive (.so .pic.a .a).<BR>
<BR>
The secret is:<BR>
<BR>
Some people worry about disk space.<BR>
<BR>
The shared library is for other packages depending on these library functions.<BR>
<BR>
The static library is so binaries in the package can link.&nbsp; The rpath is not known at compile time.&nbsp; It is only known when our internal release system is done.&nbsp; Some people don't want a wrapper script setting the LD_LIBRARY_PATH.&nbsp; Others don't want to hack the binary to encode the proper rpath after the fact.<BR>
<BR>
Don't worry, this code is for internal use only.<BR>
<BR>
Regards,<BR>
<BR>
Juan<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: cmake-bounces+juan.sanchez=amd.com@cmake.org on behalf of Goswin von Brederlow<BR>
Sent: Thu 9/13/2007 7:06 PM<BR>
To: Brandon Van Every<BR>
Cc: cmake@cmake.org<BR>
Subject: Re: [CMake] faq update?<BR>
<BR>
&quot;Brandon Van Every&quot; &lt;bvanevery@gmail.com&gt; writes:<BR>
<BR>
&gt; On 9/13/07, Juan Sanchez &lt;Juan.Sanchez@amd.com&gt; wrote:<BR>
&gt;&gt; The statement in the FAQ is untrue:<BR>
&gt;&gt;<BR>
&gt;&gt; &gt;&gt; That means I have to build all my library objects twice, once for shared<BR>
&gt;&gt; &gt;&gt; and once for static. I don't like that!<BR>
&gt;&gt;<BR>
&gt;&gt; This statement may also be a dealbreaker for those maintaining huge<BR>
&gt;&gt; projects.<BR>
&gt;<BR>
&gt; You know, if you're as huge as AMD, you've got the bucks to find<BR>
&gt; workarounds.&nbsp; You could even pay Kitware to implement something<BR>
&gt; better.&nbsp; The vast majority of CMake developers should be doing<BR>
&gt; whatever works reliably.<BR>
&gt;<BR>
&gt;&gt; If we choose to use the exact same flags, why shouldn't we be able to<BR>
&gt;&gt; choose to create the shared library from the archive?<BR>
<BR>
If you are involved in such a big project and still don't know that<BR>
you can't use the exact same flags for static and dynamic then lets<BR>
hope I never have to use it. I was positivly surprised how automatic<BR>
building static and dynmic libs works in cmake.<BR>
<BR>
For dynamic code (in C/C++/obj-c/fortran/anythign with C linkage) you<BR>
must use -fPIC or variant thereof because otherwise your jump labels<BR>
will be too small and linking will fail sometimes on x86, nearly<BR>
always on amd64, ppc, always on ia64, hppa, ...<BR>
<BR>
And if you build static code with -fPIC then you get the reverse on<BR>
some archs and loose, some claim up to 30%, speed on x86 and amd64.<BR>
<BR>
<BR>
Consider yourself lucky you only have to build 2 versions. You might<BR>
have to build a dynamic library (*.so), a static library for use in static<BR>
linking (*.a) and a static library for use in dynamic linking<BR>
(*_pic.a, to link into another dynamic lib or library reduction in an<BR>
installer image).<BR>
<BR>
MfG<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Goswin<BR>
_______________________________________________<BR>
CMake mailing list<BR>
CMake@cmake.org<BR>
<A HREF="http://www.cmake.org/mailman/listinfo/cmake">http://www.cmake.org/mailman/listinfo/cmake</A><BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>