Re: [CMake] link problem with cmake
On 10/5/08, Alexander Neundorf [EMAIL PROTECTED] wrote:
On Sunday 05 October 2008, 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
Does cmake support whole-archive now ? I didn't know that.
kind of...
I have done the followig ugly thing to make cmake support it:
if(CMAKE_COMPILER_IS_GNUCXX)
set(WEBKKIT_LD_FLAGS -Wl,-whole-archive -lbalwtf -lkjs -lwebcore
-Wl,-no-whole-archive)
endif(CMAKE_COMPILER_IS_GNUCXX)
target_link_libraries(webkit-owb
${WEBKKIT_LD_FLAGS}
${EXTERNAL_DEPS_LIBRARIES}
)
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.
Please use at cmake = 2.6.2.
Then specifiy the link interface of webkit, it's now done with a new
argument to target_link_libraries().
target_link_libraries(webkit kjs balwtf webcore)
target_link_libraries(webkit LINK_INTERFACE_LIBRARIES ) - makes the link
interface empty.
I hope I remember correctly, since I didn't test this right now.
Thanks, after an update to cmake 2.6.2 it perfectly works.
Alex
Regards,
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Olivier DOLE
Pleyo
Software Engineer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] link problem with cmake
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. Regards, -- Olivier DOLE Pleyo Software Engineer ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link problem with cmake
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 __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link problem with cmake
On Sunday 05 October 2008, 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 Does cmake support whole-archive now ? I didn't know that. 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. Please use at cmake = 2.6.2. Then specifiy the link interface of webkit, it's now done with a new argument to target_link_libraries(). target_link_libraries(webkit kjs balwtf webcore) target_link_libraries(webkit LINK_INTERFACE_LIBRARIES ) - makes the link interface empty. I hope I remember correctly, since I didn't test this right now. Alex Regards, ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
