[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
[CMake] Need help with building with cmake and make
Hi, I am trying to install a software that uses boost and some other programs as well. I am using cmake to build the environment. However, I get the following error messages: (1) This is what I get when I run cmake ./ [EMAIL PROTECTED]:~/Work/fers-beta1$ sudo cmake ./ [sudo] password for shital: -- found PYTHONLIBS_FOUND FALSE -- Could NOT find PythonLibs -- found PYTHONLIBS_FOUND FALSE -- Could NOT find PythonLibs -- found PYTHONLIBS_FOUND FALSE -- Could NOT find PythonLibs -- found PYTHONLIBS_FOUND FALSE -- Could NOT find PythonLibs -- Configuring done Warning: Ignoring path found in link libraries for target: fers, path is: /usr/local/lib. Expected a library name or a full path to a library name. Warning: Ignoring path found in link libraries for target: fers, path is: /usr/local/lib. Expected a library name or a full path to a library name. Warning: Ignoring path found in link libraries for target: clock_test, path is: /usr/local/lib. Expected a library name or a full path to a library name. Warning: Ignoring path found in link libraries for target: filter_test, path is: /usr/local/lib. Expected a library name or a full path to a library name. Warning: Ignoring path found in link libraries for target: noisegen_test, path is: /usr/local/lib. Expected a library name or a full path to a library name. Warning: Ignoring path found in link libraries for target: timing_test, path is: /usr/local/lib. Expected a library name or a full path to a library name. -- Generating done -- Build files have been written to: /home/shital/Work/fers-beta1 (2) Then when I run make , I get the following errors messages: [EMAIL PROTECTED]:~/Work/fers-beta1$ make /usr/bin/cmake -H/home/shital/Work/fers-beta1 -B/home/shital/Work/fers-beta1 --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /home/shital/Work/fers-beta1/CMakeFiles 66 make -f CMakeFiles/Makefile2 all make[1]: Entering directory `/home/shital/Work/fers-beta1' make -f tinyxml/CMakeFiles/tinyxml.dir/build.make tinyxml/CMakeFiles/tinyxml.dir/depend make[2]: Entering directory `/home/shital/Work/fers-beta1' make[2]: Nothing to be done for `tinyxml/CMakeFiles/tinyxml.dir/depend'. make[2]: Leaving directory `/home/shital/Work/fers-beta1' make -f tinyxml/CMakeFiles/tinyxml.dir/build.make tinyxml/CMakeFiles/tinyxml.dir/build make[2]: Entering directory `/home/shital/Work/fers-beta1' make[2]: Nothing to be done for `tinyxml/CMakeFiles/tinyxml.dir/build'. make[2]: Leaving directory `/home/shital/Work/fers-beta1' /usr/bin/cmake -E cmake_progress_report /home/shital/Work/fers-beta1/CMakeFiles 1 2 3 [ 6%] Built target tinyxml make -f fftwcpp/CMakeFiles/fftwcpp.dir/build.make fftwcpp/CMakeFiles/fftwcpp.dir/depend make[2]: Entering directory `/home/shital/Work/fers-beta1' make[2]: Nothing to be done for `fftwcpp/CMakeFiles/fftwcpp.dir/depend'. make[2]: Leaving directory `/home/shital/Work/fers-beta1' make -f fftwcpp/CMakeFiles/fftwcpp.dir/build.make fftwcpp/CMakeFiles/fftwcpp.dir/build make[2]: Entering directory `/home/shital/Work/fers-beta1' /usr/bin/cmake -E cmake_progress_report /home/shital/Work/fers-beta1/CMakeFiles 4 [ 6%] Building CXX object fftwcpp/CMakeFiles/fftwcpp.dir/fftwcpp.o /usr/bin/c++ -g -Wall -pthread -O2 -ffast-math -g -I/home/shital/Work/fers-beta1/fftwcpp -I/home/shital/Work/fers-beta1 -D_REENTRANT -o fftwcpp/CMakeFiles/fftwcpp.dir/fftwcpp.o -c /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp In file included from /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:11: /usr/local/include/boost-1_36/boost/thread/mutex.hpp:12:44: error: boost/thread/detail/platform.hpp: No such file or directory /usr/local/include/boost-1_36/boost/thread/mutex.hpp:18:2: error: #error Boost threads unavailable on this platform /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:16: error: 'boost' has not been declared /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:16: error: expected constructor, destructor, or type conversion before 'plannerMutex' /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp: In constructor 'FFTComplex::FFTComplex(int, Complex*, Complex*, FFTComplex::fft_direction)': /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:158: error: 'boost' has not been declared /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:158: error: expected `;' before 'lock' /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp: In destructor 'FFTComplex::~FFTComplex()': /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:167: error: 'boost' has not been declared /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:167: error: expected `;' before 'lock' /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp: In constructor 'FFTRealForward::FFTRealForward(int, double*, Complex*)': /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:187: error: 'boost' has not been declared /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:187: error: expected `;' before 'lock' /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp: In destructor 'FFTRealForward::~FFTRealForward()':
Re: [CMake] Need help with building with cmake and make
On 06.10.08 01:22:07, Shital Desai wrote: Hi, I am trying to install a software that uses boost and some other programs as well. I am using cmake to build the environment. However, I get the following error messages: (1) This is what I get when I run cmake ./ Bad idea, use a separate builddir, much easier to clean up when something goes wrong. [EMAIL PROTECTED]:~/Work/fers-beta1$ sudo cmake ./ Why do you run cmake as root? [sudo] password for shital: -- found PYTHONLIBS_FOUND FALSE -- Could NOT find PythonLibs -- found PYTHONLIBS_FOUND FALSE -- Could NOT find PythonLibs -- found PYTHONLIBS_FOUND FALSE -- Could NOT find PythonLibs -- found PYTHONLIBS_FOUND FALSE -- Could NOT find PythonLibs -- Configuring done This indicates an unclean builddir, there is much more output in the initial run. If you're properly using find_package(Boost) then information about the found boost version is also included. (2) Then when I run make , I get the following errors messages: [ 6%] Building CXX object fftwcpp/CMakeFiles/fftwcpp.dir/fftwcpp.o /usr/bin/c++ -g -Wall -pthread -O2 -ffast-math -g -I/home/shital/Work/fers-beta1/fftwcpp -I/home/shital/Work/fers-beta1 -D_REENTRANT -o fftwcpp/CMakeFiles/fftwcpp.dir/fftwcpp.o -c /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp In file included from /home/shital/Work/fers-beta1/fftwcpp/fftwcpp.cpp:11: /usr/local/include/boost-1_36/boost/thread/mutex.hpp:12:44: error: boost/thread/detail/platform.hpp: No such file or directory Either you didn't search for boost, it wasn't found or you forgot the include_directories() call for the boost-include directory. Which cmake version are you using? Andreas -- Increased knowledge will help you now. Have mate's phone bugged. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Backslash expansion of double quotes different for MinGW and Unix generators
Hi (Bill / Alex),
CMakeLists.txt
I've recently been getting my CMake project building under Linux as well
as my existing Windows MinGW environment.
One difference that cropped up is the following custom rule, which
builds a header file with svn revision number in it (simplified in this
example). The escaping of the double quotes seems to behave differently
for the CMake MinGW and Unix generators, with the Unix version
mucking up the handling of the backslash double quoted escapes.
See example dummy project below (file also attached):
PROJECT (test)
ADD_CUSTOM_TARGET (
SvnRevision ALL
${CMAKE_COMMAND} -E echo 1234 svnrevision.txt
#
# This works under cmake version 2.4-patch 6 running under
Windows with -GMinGW Makefiles
#
# This fails under cmake version 2.4-patch 7 running under Linux
with -GUnix Makefiles
#
# Backslash escapes seem to fail with Unix generator under both
O/S, see generated makefile rule in:
#
# .../CMakeFiles/SvnRevision.dir/build.make
#
# CMakeFiles/SvnRevision:
# /usr/bin/cmake -E echo 1234 svnrevision.txt
# sed -e s/\(.*\)/#define\ SVN_REVISION\ \ r\1\/
svnrevision.txt svnrevision.h
#
# Inner two double quotes should have been retained, but instead
last two have been generated.
#
# FYI, Windows MinGW Makefiles generator generates this:
#
# sed -e s/\(.*\)/#define SVN_REVISION \ r\1\/
svnrevision.txt svnrevision.h
#
# FYI, Windows Unix Makefiles generator generates the same as
when running on Linux:
#
# sed -e s/\(.*\)/#define\ SVN_REVISION\ \ r\1\/
svnrevision.txt svnrevision.h
#
#
# PS: Unsure way there is an extra space in front of r\1 in
both.
#
#
COMMAND sed -e s/\\(.*\\)/#define SVN_REVISION \\r\\1\\/ \\
svnrevision.txt svnrevision.h
# Dummy command without any backslashes just to prove basic rule
is OK
#COMMAND ${CMAKE_COMMAND} -E echo \\#define \\ SVN_REVISION
\\ svnrevision.h
)
Any idea what's going on here?
The only workaround to avoid use of sed is either put the sed edit
rule in a file, or use a CMake template (e.g. svnrevision.h.in) and
replace with a variable read in from a file containing svn version.
-Trev
PROJECT (test)
ADD_CUSTOM_TARGET ( SvnRevision ALL
${CMAKE_COMMAND} -E echo 1234
svnrevision.txt
#
# This works under cmake version
2.4-patch 6 running under Windows with -GMinGW Makefiles
#
# This fails under cmake version
2.4-patch 7 running under Linux with -GUnix Makefiles
#
# Backslash escapes seem to fail with
Unix generator under both O/S, see generated makefile rule in:
#
#
.../CMakeFiles/SvnRevision.dir/build.make
#
# CMakeFiles/SvnRevision:
# /usr/bin/cmake -E echo 1234
svnrevision.txt
# sed -e s/\(.*\)/#define\
SVN_REVISION\ \ r\1\/ svnrevision.txt svnrevision.h
#
# Inner two double quotes should have
been retained, but instead last two have been generated.
#
# FYI, Windows MinGW Makefiles
generator generates this:
#
# sed -e s/\(.*\)/#define
SVN_REVISION \ r\1\/ svnrevision.txt svnrevision.h
#
# FYI, Windows Unix Makefiles
generator generates the same as when running on Linux:
#
# sed -e s/\(.*\)/#define\
SVN_REVISION\ \ r\1\/ svnrevision.txt svnrevision.h
#
#
# PS: Unsure way there is an extra
space in front of r\1 in both.
#
#
COMMAND sed -e s/\\(.*\\)/#define SVN_REVISION
\\r\\1\\/ svnrevision.txt svnrevision.h
# Dummy command without any backslashes
just to prove basic rule is OK
#COMMAND ${CMAKE_COMMAND} -E echo
\\#define SVN_REVISION \\ svnrevision.h
)
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
[CMake] WIN32_EXECUTABLE - Config specific settings for visual studio generated project files?
Hello, I am wondering if it is possible to set the target property ' WIN32_EXECUTABLE' on a per-config basis (i.e. you can set link-flags on a per-config basis using LINK_FLAGS_Config). From reading the documentation this does not seem possible and if you set this property then all configurations (in Visual Studio) use the same subsystem setting. My desired behavior is to have debug builds running from a console but release mode builds running as a pseudo-WinMain without having to re-run CMake generation. Is it possible to set the subsystem setting somewhere else since this is a Visual Studio only practice (I assume). It is common practice for win32 developers to change this setting per-config as it allows for extra debug information to be visible when it is needed and to be hidden when it is not. If this is not possible what are the steps to see this evaluated as a feature request? If submitting this as a feature request is not possible, what are the steps for submitting a patch, as I am confident I can implement this feature personally. Thanks! Jason ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
