[CMake] more linking problems

[Alexander Neundorf]

Hi Brad, 
 
> Alexander Neundorf wrote: 
...  
> > 1) how do I link to a shared library which isn't installed yet ?  
> > I added lines like this one:  
> > ${CMAKE_BINARY_DIR}/lib/interfaces/external/libkinterfacedesigner.so 
>  
> Turn on CMAKE_SKIP_RPATH to avoid getting the build-tree rpath compiled  
> in and then just specify the library by name "kinterfacedesigner". 
 
You mean like: 
TARGET_LINK_LIBRARIES (blah 
${CMAKE_BINARY_DIR}/lib/interfaces/external/kinterfacedesigner ) ? 
 
And this will work ? 
 
> install location should not matter as long as the system is configured  
> with the proper library search paths.  Several linux distributions ban  
> rpaths from their binaries, so avoiding rpaths is generally considered  
> good for installed packages.  CMake adds rpaths by default so that  
> shared-library builds can work out-of-the-box from the build tree. 
 
Ah, ok. 
(What is actually the rpath ?) 
  
> > 2) In kdevelop libkdevelop links to several shared libs and also to 
some 
> > static libs. E.g. libkdevinterfaces.a is approx. 500 kb big and the 
> stuff  
> > contained in it should be contained in the resulting libkdevelop. But  
> > with the given link command this isn't the case. The resulting  
> > libkdevelop is only about 6 kb big and doesn't contain the objects 
from  
> > the static libs it linked to. 
> > Is there a way to achieve this ? 
>  
> When a static library is linked using -lmylib objects from it will only  
> be included if something references a symbol from them.  Some linkers  
> (but I don't think all) will copy the entire static library if linked  
> with the full name of the archive (libmylib.a). 
 
Ok, that's the behaviour I see. 
I know that when kde is linked it works. And although it uses libtool, in 
the end it must come down to ld. I'll have a closer look what's going on 
when linking it with libtool. (I know there's a warning about 
portability). 
  
> As far as I know the only cross-platform reliable way to get everything  
> into the shared library is to create a source file in the shared 
library  
> that references at least one symbol from every object in the static  
> library.  The symbol doesn't need to do anything it just needs to be  
> referenced.  One symbol per object file should do it.  Even then the  
 
This doesn't sound good. It wouldn't be a good solution. I don't think I 
would manage to create these files automatically with cmake. There are a 
lot of such static libs in KDE. 
 
> symbols may not be exported from the shared library and available for  
> use by other code.  This depends whether the objects in the static  
> library were compiled with a flag like -fPIC.  The behavior is  
> platform-dependent, but on Linux at least everything is compiled  
> "sharable" by default. 
>  
> Alternatively you can do the restructing to put all the sources into  
> the same shared library. 
 
I don't think I can do this. If compiling KDE with cmake would require 
changes in the code then cmake is out of the game. 
 
Now I found something in the mailing list archive:  
http://public.kitware.com/pipermail/cmake/2004-December/005907.html 
I think I'll try this. Would it be also possible to add a static lib 
there ? 
 
> > 3) In the kdevelop tree there are two targets "kdevelop": a library  
> > ADD_LIBRARY(kdevelop ...) and a binary ADD_EXECUTABLE(kdevelop ...) 
in  
> > different directories.  
>  
> This is currently a CMake limitation.  There can be only one target 
with  
> a given name anywhere in the build tree.  The reason is that Visual  
> Studio solutions/workspaces must have unique names for the projects in  
> them.  Each project corresponds to a library or executable.  Therefore  
> they must have unique names.  Eventually we might do some kind of name  
> encoding based on the source directory where the target was added but  
> this is not yet implemented. 
>  
> You can get around this problem by splitting the build process into two  
> pieces.  The main build will create all the libraries and utility  
> executables.  At the end of this build you can have a custom command  
> that runs ctest --build-and-test to drive a second build process in a  
> subdirectory.  This is done in VTK right now to build the examples  
> using a single target in the top-level build process. 
 
This sounds problematic. I'll see what I can do. 
 
Bye 
Alex 
 

-- 
+++ NEU: GMX DSL_Flatrate! Schon ab 14,99 EUR/Monat! +++

GMX Garantie: Surfen ohne Tempo-Limit! http://www.gmx.net/de/go/dsl