[CMake] link problem with cmake

[Alan W. Irwin]

On 2008-10-05 16:07+0200 Oliver Dole wrote:

> Hello,
>
> I have a link problem with cmake on Linux.
> I work on owb, a webkit based browser, which uses cmake as build
> system. Here is how my cmake system works:
> - build balwtf.a, kjs.a and webcore.a
> - build libwebkit.so which requires balwtf.a, kjs.a and webcore.a
> - then I build owb.
>> From my point of view to do a correct link on linux, I simply should do:
> g++ -c main.cpp.o -lwebkit -o owb
> Unfortunately, by default cmake transitively links to targets with
> which the library itself was linked.
> so my link is currently the following:
> g++ -c main.cpp.o -lwebkit -Wl,--whole-archive -lbalwtf -lkjs
> -lwebcore.... -o owb
> It seems that there is something to do with LINK_INTERFACE_LIBRARIES
> to remove the default behaviour, but I do not know what. So any help
> on how to archieve that is welcome.

For the pure shared library case (which I admit yours is not), are there any
practical bad consequences on Linux of using transitive linking? I think
CMake has always used this model.  (If CMake is instructed that shared
library a links to the b shared library target only, and library b links to
the c shared library target only, then the actual link for liba generated by
CMake will mention both libb and libcc.) autotools played with the idea of
using "simple" linking on Linux, but they (as of several years ago when I
last checked) settled on transitive linking.  font-config also normally uses
transitive linking.  From these examples, I assume there are some situations
on Linux where transitive linking is essential for shared libraries, and I
am unaware of any situations where it hurts.  Again, these comments just
pertain to the pure shared libraries case where I have virtually all my
linking experience.

Of course, your libwebkit is linked to the static libraries balwtf.a, kjs.a
and webcore.a so there should never be any need to link to those libraries
for main.cpp (unless that code specifically refers to symbols in those static
libraries). Also, I just looked up --whole-archive and that sounds like your
resulting application is going to be huge for no reason.

My experience for the pure shared libraries case is CMake always does the
right thing.  Of course, that may not happen for this mixed case, but I am
wondering if there is a problem with your CMakeLists.txt files so that your
application is being specifically asked to link to the static libraries
rather than just the target associated with libwebkit.

For an overall check of symbol resolution and also to list the shared
libraries that will be used at run time, I suggest "ldd -r" for your
application and your shared libraries.  To see what symbols need to be
resolved by main.cpp.o and what symbols are supplied by the various
libraries, try the nm application.  I believe for the *.a case you will have
to unpack the ar archive to access the various object modules in the library
with nm so that case is more complicated, but doable.

HTH.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________