Re: [cmake-developers] Some documentation patches
Brad King wrote: - Some of the patches remove trailing whitespace from lines unrelated to the real change. Please identify the set of files from which you've blanket-removed whitespace, create a commit that does just that, and then rebase the rest of the patches on it. That will make the changes easier to see/review/blame. sed 's,[ \t]*$,,' -i $(find . -type f) HTH, Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094 On gentoo, the build of the exec executable succeeds, even though it only links to libC, and that only links to libA, even though it uses classB from libB (which is not linked to). Can someone with access to that box check if the result actually runs? For easyness of testing you can use either of the two tarballs I send to this thread already. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094 On gentoo, the build of the exec executable succeeds, even though it only links to libC, and that only links to libA, even though it uses classB from libB (which is not linked to). Can someone with access to that box check if the result actually runs? For easyness of testing you can use either of the two tarballs I send to this thread already. I will have a look later. But this can be just a general screwup, the toolchain on HPPA is know to have some strange bugs. So at the end this may just end in another binutils/gcc/whatever bugreport. So until I have looked into this I would say you should ignore this failure, it is too likely to be entirely unrelated. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094 On gentoo, the build of the exec executable succeeds, even though it only links to libC, and that only links to libA, even though it uses classB from libB (which is not linked to). libB is in the needed section (see below). The only special thing that I can think of is the -Wl,--unique=.text.* flag I put into C_FLAGS, as CMake itself would otherwise not link because of a binutils breakage. No idea if that is related. buildbot@voyager ~/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/fail19 $ ll total 36 -rw-r--r-- 1 buildbot buildbot 9772 Oct 13 15:51 CMakeCache.txt drwxr-xr-x 3 buildbot buildbot 4096 Oct 13 16:04 CMakeFiles -rw-r--r-- 1 buildbot buildbot 1753 Oct 13 15:51 cmake_install.cmake -rwxr-xr-x 1 buildbot buildbot 7768 Oct 13 16:04 exec -rw-r--r-- 1 buildbot buildbot 4956 Oct 13 16:04 Makefile buildbot@voyager ~/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/fail19 $ ./exec buildbot@voyager ~/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/fail19 $ echo $? 0 buildbot@voyager ~/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/fail19 $ ldd exec liblibC.so = /home/buildbot/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_False/liblibC.so (0x401ca000) libstdc++.so.6 = /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/libstdc++.so.6 (0x403a5000) libm.so.6 = /lib/libm.so.6 (0x405b3000) libgcc_s.so.4 = /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/libgcc_s.so.4 (0x407d3000) libc.so.6 = /lib/libc.so.6 (0x4096b000) liblibB.so = /home/buildbot/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_False/liblibB.so (0x401c5000) liblibA.so = /home/buildbot/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_False/liblibA.so (0x40241000) /lib/ld.so.1 (0x40063000) buildbot@voyager ~/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/fail19 $ objdump -x exec exec: file format elf32-hppa-linux exec architecture: hppa1.1, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x00010650 Program Header: PHDR off0x0034 vaddr 0x00010034 paddr 0x00010034 align 2**2 filesz 0x0100 memsz 0x0100 flags r-x INTERP off0x0134 vaddr 0x00010134 paddr 0x00010134 align 2**0 filesz 0x000d memsz 0x000d flags r-- LOAD off0x vaddr 0x0001 paddr 0x0001 align 2**12 filesz 0x0be4 memsz 0x0be4 flags r-x LOAD off0x1000 vaddr 0x00011000 paddr 0x00011000 align 2**12 filesz 0x019c memsz 0x01b0 flags rwx DYNAMIC off0x1014 vaddr 0x00011014 paddr 0x00011014 align 2**2 filesz 0x0108 memsz 0x0108 flags rw- NOTE off0x0144 vaddr 0x00010144 paddr 0x00010144 align 2**2 filesz 0x0020 memsz 0x0020 flags r-- EH_FRAME off0x0b74 vaddr 0x00010b74 paddr 0x00010b74 align 2**2 filesz 0x001c memsz 0x001c flags r-- PAX_FLAGS off0x vaddr 0x paddr 0x align 2**2 filesz 0x memsz 0x flags --- 2800 Dynamic Section: NEEDED liblibC.so NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.4 NEEDED libc.so.6 NEEDED liblibB.so RPATH /home/buildbot/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_False RUNPATH /home/buildbot/repos/build/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_False INIT 0x000105e8 FINI 0x00010a54 HASH 0x00010164 GNU_HASH 0x00010200 STRTAB 0x000103a8 SYMTAB 0x00010268 STRSZ0x0179 SYMENT 0x0010 PLTGOT 0x000c DEBUG0x PLTRELSZ 0x0060 PLTREL 0x0007 JMPREL 0x00010578 RELA 0x0001056c RELASZ 0x000c RELAENT 0x000c VERNEED 0x0001054c VERNEEDNUM 0x0001 VERSYM 0x00010522 Version References: required from libc.so.6: 0x0d696912 0x00 02 GLIBC_2.2 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 000d 00010134 00010134 0134 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 0020 00010144 00010144 0144 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 009c 00010164 00010164 0164 2**2
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094 On gentoo, the build of the exec executable succeeds, even though it only links to libC, and that only links to libA, even though it uses classB from libB (which is not linked to). libB is in the needed section (see below). The only special thing that I can think of is the -Wl,--unique=.text.* flag I put into C_FLAGS, as CMake itself would otherwise not link because of a binutils breakage. No idea if that is related. Ok, it is not related. I rebuild only that testcase without that flag and it did not change anything. But I noticed another thing. In the dashboard above 2 tests are failing: 19 and 20. I think the test #20 is actually wrong, as it seems to depend on linker flags that may just be activated by default on the machines you use. If I manually specify LDFLAGS=-Wl,--no-copy-dt-needed-entries,--as-needed when I call CMake for the first time #20 succeeds for me. So it looks like this is just accidentially working, but in fact you may need to pass these flags yourself to make sure they are always there. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
Rolf Eike Beer wrote: Stephen Kelly wrote: The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094 On gentoo, the build of the exec executable succeeds, even though it only links to libC, and that only links to libA, even though it uses classB from libB (which is not linked to). libB is in the needed section (see below). The only special thing that I can think of is the -Wl,--unique=.text.* flag I put into C_FLAGS, as CMake itself would otherwise not link because of a binutils breakage. No idea if that is related. Ok, it is not related. I rebuild only that testcase without that flag and it did not change anything. But I noticed another thing. In the dashboard above 2 tests are failing: 19 and 20. I think the test #20 is actually wrong, as it seems to depend on linker flags that may just be activated by default on the machines you use. If I manually specify LDFLAGS=-Wl,--no-copy-dt-needed-entries,--as-needed when I call CMake for the first time #20 succeeds for me. So it looks like this is just accidentially working, but in fact you may need to pass these flags yourself to make sure they are always there. You mean everyone needs to specify them if they use LINK_INTERFACE_LIBRARIES anywhere, right? If that's true then setting that variable to empty should maybe add those flags automatically. I'm not certain that's correct though. Those flags don't seem to be used when I build. I also don't know what those flags do. Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/lib/icecc/bin/c++ CMakeFiles/exec.dir/main.cpp.o -o exec - rdynamic lib/liblibC.so -Wl,-rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath-link,/home/stephen/cmaketest/test19/build/lib CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' collect2: ld returned 1 exit status make[2]: *** [exec] Error 1 make[2]: Leaving directory `/home/stephen/cmaketest/test19/build' Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
Rolf Eike Beer wrote: Stephen Kelly wrote: The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016build=1620094 On gentoo, the build of the exec executable succeeds, even though it only links to libC, and that only links to libA, even though it uses classB from libB (which is not linked to). libB is in the needed section (see below). The only special thing that I can think of is the -Wl,--unique=.text.* flag I put into C_FLAGS, as CMake itself would otherwise not link because of a binutils breakage. No idea if that is related. Ok, it is not related. I rebuild only that testcase without that flag and it did not change anything. But I noticed another thing. In the dashboard above 2 tests are failing: 19 and 20. I think the test #20 is actually wrong, as it seems to depend on linker flags that may just be activated by default on the machines you use. If I manually specify LDFLAGS=-Wl,--no-copy-dt-needed-entries,--as-needed when I call CMake for the first time #20 succeeds for me. So it looks like this is just accidentially working, but in fact you may need to pass these flags yourself to make sure they are always there. You mean everyone needs to specify them if they use LINK_INTERFACE_LIBRARIES anywhere, right? I don't meant that. What does not mean that this may not be true. I just have no idea ;) It may even mean that you have to test if that works at all, older binutils may not have this. I don't know. If that's true then setting that variable to empty should maybe add those flags automatically. I'm not certain that's correct though. Those flags don't seem to be used when I build. I also don't know what those flags do. Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/lib/icecc/bin/c++ CMakeFiles/exec.dir/main.cpp.o -o exec - rdynamic lib/liblibC.so -Wl,-rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath-link,/home/stephen/cmaketest/test19/build/lib CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' collect2: ld returned 1 exit status make[2]: *** [exec] Error 1 make[2]: Leaving directory `/home/stephen/cmaketest/test19/build' Maybe this is just the default setting for your binutils. Try LDFLAGS=-Wl,--copy-dt-needed-entries,-no-as-needed and see what happens. I bet this will change the behavior on your system. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
Rolf Eike Beer wrote: I'm not certain that's correct though. Those flags don't seem to be used when I build. I also don't know what those flags do. Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/lib/icecc/bin/c++ CMakeFiles/exec.dir/main.cpp.o -o exec - rdynamic lib/liblibC.so -Wl,-rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath-link,/home/stephen/cmaketest/test19/build/lib CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' collect2: ld returned 1 exit status make[2]: *** [exec] Error 1 make[2]: Leaving directory `/home/stephen/cmaketest/test19/build' Maybe this is just the default setting for your binutils. Try LDFLAGS=-Wl,--copy-dt-needed-entries,-no-as-needed and see what happens. I bet this will change the behavior on your system. ld now gives a new error: /usr/bin/ld: error: --copy-dt-needed-entries is not supported but is required for liblibA.so in lib/liblibC.so Here's a more complete fragment: Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/lib/icecc/bin/c++ -Wl,--copy-dt-needed-entries,-no-as-needed CMakeFiles/exec.dir/main.cpp.o -o exec -rdynamic lib/liblibC.so -Wl,- rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath- link,/home/stephen/cmaketest/test19/build/lib /usr/bin/ld: error: --copy-dt-needed-entries is not supported but is required for liblibA.so in lib/liblibC.so CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' collect2: ld returned 1 exit status I also ran ctest -V -R target_link_librares with those flags and many more tests failed. I have no idea what those flags do, so I don't know if that new error is a lead. This may be new in my binutils version. Can you just try LDFLAGS=-Wl,-no-as-needed? Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
On Thu, Oct 13, 2011 at 4:33 PM, Richard Wackerbarth rich...@nfsnet.org wrote: Steve, Here is the output from the version of test19 that you sent privately. The version of cmake was built with last night's dashboard. I don't see the failure here. Am I doing something wrong? Hi, it doesn't look like you're doing anything wrong. I'm definitely not an expert in linker flags, options and outputs though. I don't know what to look for to find out why that is linking successfully anyway even though it does not link to libB. The only thing I was looking for was the linker invocation which shows that the executable is linked to libC but not libB. Does any cmake developer have any idea how this could happen? Thanks, Steve. Richard [rkw@Chameleon-12 ~/test19-build]$ rm -rf * [rkw@Chameleon-12 ~/test19-build]$ /usr/local/bin/cmake --version cmake version 2.8.6.20111012-gb6440 [rkw@Chameleon-12 ~/test19-build]$ cmake ../test19 -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success -- Performing Test COMPILER_HAS_DEPRECATED_ATTR -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success -- Configuring done -- Generating done -- Build files have been written to: /home/rkw/test19-build [rkw@Chameleon-12 ~/test19-build]$ make /usr/local/bin/cmake -H/home/rkw/test19 -B/home/rkw/test19-build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/bin/cmake -E cmake_progress_start /home/rkw/test19-build/CMakeFiles /home/rkw/test19-build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make -f lib/CMakeFiles/libA.dir/build.make lib/CMakeFiles/libA.dir/depend cd /home/rkw/test19-build /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/rkw/test19 /home/rkw/test19/lib /home/rkw/test19-build /home/rkw/test19-build/lib /home/rkw/test19-build/lib/CMakeFiles/libA.dir/DependInfo.cmake --color= Scanning dependencies of target libA make -f lib/CMakeFiles/libA.dir/build.make lib/CMakeFiles/libA.dir/build /usr/local/bin/cmake -E cmake_progress_report /home/rkw/test19-build/CMakeFiles 2 [ 25%] Building CXX object lib/CMakeFiles/libA.dir/classA.cpp.o cd /home/rkw/test19-build/lib /usr/bin/c++ -DlibA_EXPORTS -fPIC -I/home/rkw/test19-build/lib -I/home/rkw/test19/lib -o CMakeFiles/libA.dir/classA.cpp.o -c /home/rkw/test19/lib/classA.cpp Linking CXX shared library liblibA.so cd /home/rkw/test19-build/lib /usr/local/bin/cmake -E cmake_link_script CMakeFiles/libA.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -shared -Wl,-soname,liblibA.so -o liblibA.so CMakeFiles/libA.dir/classA.cpp.o /usr/local/bin/cmake -E cmake_progress_report /home/rkw/test19-build/CMakeFiles 2 [ 25%] Built target libA make -f lib/CMakeFiles/libB.dir/build.make lib/CMakeFiles/libB.dir/depend cd /home/rkw/test19-build /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/rkw/test19 /home/rkw/test19/lib /home/rkw/test19-build /home/rkw/test19-build/lib /home/rkw/test19-build/lib/CMakeFiles/libB.dir/DependInfo.cmake --color= Scanning dependencies of target libB make -f lib/CMakeFiles/libB.dir/build.make lib/CMakeFiles/libB.dir/build /usr/local/bin/cmake -E cmake_progress_report /home/rkw/test19-build/CMakeFiles 3 [ 50%] Building CXX object lib/CMakeFiles/libB.dir/classB.cpp.o cd /home/rkw/test19-build/lib /usr/bin/c++ -DlibB_EXPORTS -fPIC -I/home/rkw/test19-build/lib -I/home/rkw/test19/lib -o CMakeFiles/libB.dir/classB.cpp.o -c /home/rkw/test19/lib/classB.cpp Linking CXX shared library liblibB.so cd /home/rkw/test19-build/lib /usr/local/bin/cmake -E cmake_link_script CMakeFiles/libB.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -shared -Wl,-soname,liblibB.so -o liblibB.so CMakeFiles/libB.dir/classB.cpp.o liblibA.so -Wl,-rpath,/home/rkw/test19-build/lib /usr/local/bin/cmake -E cmake_progress_report /home/rkw/test19-build/CMakeFiles 3 [ 50%] Built target libB make -f lib/CMakeFiles/libC.dir/build.make lib/CMakeFiles/libC.dir/depend cd /home/rkw/test19-build /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/rkw/test19 /home/rkw/test19/lib /home/rkw/test19-build /home/rkw/test19-build/lib /home/rkw/test19-build/lib/CMakeFiles/libC.dir/DependInfo.cmake --color= Scanning dependencies of target libC make -f lib/CMakeFiles/libC.dir/build.make lib/CMakeFiles/libC.dir/build /usr/local/bin/cmake -E
Re: [cmake-developers] Apple tests for target_link_libraries failing
On Thu, Oct 13, 2011 at 12:01 PM, Stephen Kelly steve...@gmail.com wrote: On Thu, Oct 13, 2011 at 4:33 PM, Richard Wackerbarth rich...@nfsnet.org wrote: Steve, Here is the output from the version of test19 that you sent privately. The version of cmake was built with last night's dashboard. I don't see the failure here. Am I doing something wrong? Hi, it doesn't look like you're doing anything wrong. I'm definitely not an expert in linker flags, options and outputs though. Not an expert...? You will be soon. :-) I don't know what to look for to find out why that is linking successfully anyway even though it does not link to libB. The only thing I was looking for was the linker invocation which shows that the executable is linked to libC but not libB. Does any cmake developer have any idea how this could happen? Not I. Also not an expert in linker flags. Thanks, Steve. Richard [rkw@Chameleon-12 ~/test19-build]$ rm -rf * [rkw@Chameleon-12 ~/test19-build]$ /usr/local/bin/cmake --version cmake version 2.8.6.20111012-gb6440 [rkw@Chameleon-12 ~/test19-build]$ cmake ../test19 -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success -- Performing Test COMPILER_HAS_DEPRECATED_ATTR -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success -- Configuring done -- Generating done -- Build files have been written to: /home/rkw/test19-build [rkw@Chameleon-12 ~/test19-build]$ make /usr/local/bin/cmake -H/home/rkw/test19 -B/home/rkw/test19-build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/bin/cmake -E cmake_progress_start /home/rkw/test19-build/CMakeFiles /home/rkw/test19-build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make -f lib/CMakeFiles/libA.dir/build.make lib/CMakeFiles/libA.dir/depend cd /home/rkw/test19-build /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/rkw/test19 /home/rkw/test19/lib /home/rkw/test19-build /home/rkw/test19-build/lib /home/rkw/test19-build/lib/CMakeFiles/libA.dir/DependInfo.cmake --color= Scanning dependencies of target libA make -f lib/CMakeFiles/libA.dir/build.make lib/CMakeFiles/libA.dir/build /usr/local/bin/cmake -E cmake_progress_report /home/rkw/test19-build/CMakeFiles 2 [ 25%] Building CXX object lib/CMakeFiles/libA.dir/classA.cpp.o cd /home/rkw/test19-build/lib /usr/bin/c++ -DlibA_EXPORTS -fPIC -I/home/rkw/test19-build/lib -I/home/rkw/test19/lib -o CMakeFiles/libA.dir/classA.cpp.o -c /home/rkw/test19/lib/classA.cpp Linking CXX shared library liblibA.so cd /home/rkw/test19-build/lib /usr/local/bin/cmake -E cmake_link_script CMakeFiles/libA.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -shared -Wl,-soname,liblibA.so -o liblibA.so CMakeFiles/libA.dir/classA.cpp.o /usr/local/bin/cmake -E cmake_progress_report /home/rkw/test19-build/CMakeFiles 2 [ 25%] Built target libA make -f lib/CMakeFiles/libB.dir/build.make lib/CMakeFiles/libB.dir/depend cd /home/rkw/test19-build /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/rkw/test19 /home/rkw/test19/lib /home/rkw/test19-build /home/rkw/test19-build/lib /home/rkw/test19-build/lib/CMakeFiles/libB.dir/DependInfo.cmake --color= Scanning dependencies of target libB make -f lib/CMakeFiles/libB.dir/build.make lib/CMakeFiles/libB.dir/build /usr/local/bin/cmake -E cmake_progress_report /home/rkw/test19-build/CMakeFiles 3 [ 50%] Building CXX object lib/CMakeFiles/libB.dir/classB.cpp.o cd /home/rkw/test19-build/lib /usr/bin/c++ -DlibB_EXPORTS -fPIC -I/home/rkw/test19-build/lib -I/home/rkw/test19/lib -o CMakeFiles/libB.dir/classB.cpp.o -c /home/rkw/test19/lib/classB.cpp Linking CXX shared library liblibB.so cd /home/rkw/test19-build/lib /usr/local/bin/cmake -E cmake_link_script CMakeFiles/libB.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -shared -Wl,-soname,liblibB.so -o liblibB.so CMakeFiles/libB.dir/classB.cpp.o liblibA.so -Wl,-rpath,/home/rkw/test19-build/lib /usr/local/bin/cmake -E cmake_progress_report /home/rkw/test19-build/CMakeFiles 3 [ 50%] Built target libB make -f lib/CMakeFiles/libC.dir/build.make lib/CMakeFiles/libC.dir/depend cd /home/rkw/test19-build /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/rkw/test19 /home/rkw/test19/lib /home/rkw/test19-build /home/rkw/test19-build/lib
Re: [cmake-developers] Some documentation patches
On Thu, Oct 13, 2011 at 8:30 AM, Rolf Eike Beer e...@sf-mail.de wrote: Brad King wrote: - Some of the patches remove trailing whitespace from lines unrelated to the real change. Please identify the set of files from which you've blanket-removed whitespace, create a commit that does just that, and then rebase the rest of the patches on it. That will make the changes easier to see/review/blame. sed 's,[ \t]*$,,' -i $(find . -type f) HTH, Thanks but this one is dangerous because it also modify your .git and just break your repository if started from the root of the project :-) -- Nicolas Desprès -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Some documentation patches
2011/10/13 Brad King brad.k...@kitware.com: On 10/12/2011 11:10 AM, Nicolas Desprès wrote: I have extracted some documentation patches I have made while I was working on the ninja-generator and some enhancement for ccmake. I would like to submit them now. They are addressing: - usage messages - doxygen documentation - online help in ccmake Fantastic. This is a lot of tedious cleanup work. Thanks for doing it! Here are a few comments from review: - The Factor toggle key help instructions commit adds lines longer than 79 characters. Please reformat them to use shorter lines. - Some of the patches remove trailing whitespace from lines unrelated to the real change. Please identify the set of files from which you've blanket-removed whitespace, create a commit that does just that, and then rebase the rest of the patches on it. That will make the changes easier to see/review/blame. - Please prefix each commit message with the section affected, when applicable. For example, ccmake: or doxygen: . Thanks for the review. I have fix all the remarks. Shall I send the patch again via the mailing list or shall I push them on github and you will fetch them. Sending many patches to the mailing list make the post moderated. Tell me what is the easiest for you. Cheers, -- Nicolas Desprès -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Some documentation patches
2011/10/13 Nicolas Desprès nicolas.desp...@gmail.com: 2011/10/13 Brad King brad.k...@kitware.com: On 10/12/2011 11:10 AM, Nicolas Desprès wrote: I have extracted some documentation patches I have made while I was working on the ninja-generator and some enhancement for ccmake. I would like to submit them now. They are addressing: - usage messages - doxygen documentation - online help in ccmake Fantastic. This is a lot of tedious cleanup work. Thanks for doing it! Here are a few comments from review: - The Factor toggle key help instructions commit adds lines longer than 79 characters. Please reformat them to use shorter lines. - Some of the patches remove trailing whitespace from lines unrelated to the real change. Please identify the set of files from which you've blanket-removed whitespace, create a commit that does just that, and then rebase the rest of the patches on it. That will make the changes easier to see/review/blame. - Please prefix each commit message with the section affected, when applicable. For example, ccmake: or doxygen: . Thanks for the review. I have fix all the remarks. Shall I send the patch again via the mailing list or shall I push them on github and you will fetch them. Sending many patches to the mailing list make the post moderated. Tell me what is the easiest for you. Pushed on my github: https://github.com/polrop/CMake/commits/some-documentation-fixes -- Nicolas Desprès -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: Ok, knowing why it fails on APPLE is good enough for me for now. The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. I was given access to a freebsd box to see why the build succeeds there. The link line looks like this: ~/test19-build]$ vi CMakeFiles/exec.dir/link.txt /usr/bin/c++ -Wl,-no-as-needed CMakeFiles/exec.dir/main.cpp.o -o exec lib/liblibC.so -Wl,-rpath,/home/steve/test19-build/lib -Wl,-rp ath-link,/home/steve/test19-build/lib and then ldd reports that it is also linked against liblibB.so. ~/test19-build]$ ldd exec exec: liblibC.so = /home/steve/test19-build/lib/liblibC.so (0x800849000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x800a4a000) libm.so.5 = /lib/libm.so.5 (0x800d55000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x800f76000) libc.so.7 = /lib/libc.so.7 (0x801183000) liblibB.so = /home/steve/test19-build/lib/liblibB.so (0x8014cb000) liblibA.so = /home/steve/test19-build/lib/liblibA.so (0x8016cc000) I can't explain why. I also tried with export LDFLAGS=-Wl,-no-as-needed with the same result. For the moment I think I'll give up on testing the actual result of the build, but I'll just compare the result with the 'control point' of building with all targets with their LINK_INTERFACE_LIBRARIES set to empty. That will be a good enough unit test for the CMAKE_LINK_INTERFACE_LIBRARIES and makes fixing all of the issues with it not my responsibility :). It also means that I don't become an expert in linker options :). Should be done tomorrow. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Some documentation patches
On 10/13/2011 2:14 PM, Nicolas Desprès wrote: 2011/10/13 Nicolas Desprèsnicolas.desp...@gmail.com: Thanks for the review. I have fix all the remarks. Pushed on my github: https://github.com/polrop/CMake/commits/some-documentation-fixes Thanks. I will fetch it from there when I get a chance to look at it again. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Some documentation patches
On 10/13/2011 2:14 PM, Nicolas Desprès wrote: 2011/10/13 Nicolas Desprèsnicolas.desp...@gmail.com: Thanks for the review. I have fix all the remarks. Pushed on my github: https://github.com/polrop/CMake/commits/some-documentation-fixes That looks pretty good. I have two more comments: - The following commits add lines over 79 characters that weren't already: ccmake: Align 'g' and 'q' key instructions. Usage: Document all options printing the version number. - The commit Doxygen: Fix warnings. modifies some *Lexer.cxx files which are actually flex-generated sources created from the *.in.l versions. The modifications to the comments should be made in both files so that the next time we regenerate the lexers the comments are preserved. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: Ok, knowing why it fails on APPLE is good enough for me for now. The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. I was given access to a freebsd box to see why the build succeeds there. The link line looks like this: ~/test19-build]$ vi CMakeFiles/exec.dir/link.txt /usr/bin/c++ -Wl,-no-as-needed CMakeFiles/exec.dir/main.cpp.o -o exec lib/liblibC.so -Wl,-rpath,/home/steve/test19-build/lib -Wl,-rp ath-link,/home/steve/test19-build/lib and then ldd reports that it is also linked against liblibB.so. ~/test19-build]$ ldd exec exec: liblibC.so = /home/steve/test19-build/lib/liblibC.so (0x800849000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x800a4a000) libm.so.5 = /lib/libm.so.5 (0x800d55000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x800f76000) libc.so.7 = /lib/libc.so.7 (0x801183000) liblibB.so = /home/steve/test19-build/lib/liblibB.so (0x8014cb000) liblibA.so = /home/steve/test19-build/lib/liblibA.so (0x8016cc000) Nope, you got that wrong. What that means is that liblibB.so will get loaded to satisfy some dynamic library dependencies when exec is called. It does not mean that exec got linked against liblibB, but that exec or any of it's dependencies was linked against liblibB. So you will likely see the very same result on any exec that was successfully linked. What you are looking for is objdump or readelf, they will tell you what is actually in exec and not in it's dependencies. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
