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] 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] 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Bill Hoffman wrote:
So, basically we this:
set(CMAKE_LINK_INTERFACE_LIBRARIES )
add_library(libA SHARED classA.cpp)
add_library(libB SHARED classB.cpp)
add_library(libC SHARED classC.cpp)
generate_export_header(libA)
generate_export_header(libB)
generate_export_header(libC)
target_link_libraries(libB libA)
target_link_libraries(libC libA libB)
add_executable(exec
main.cpp
)
target_link_libraries(exec libC )
So, setting CMAKE_LINK_INTERFACE_LIBRARIES to is supposed to make the
transitive linking of A and B not happen when linking C. I tried adding
some print stuff in the code. But, I am not sure where to look.
I added the following:
void cmTarget::SetPropertyDefault(const char* property,
const char* default_value)
{
+ bool debug = false;
+ if(strcmp(LINK_INTERFACE_LIBRARIES, property) == 0)
+debug = true;
+ if(debug) std::cerr this-GetName() \n;
// Compute the name of the variable holding the default value.
std::string var = CMAKE_;
var += property;
-
+ if(debug) std::cerr var \n;
if(const char* value = this-Makefile-GetDefinition(var.c_str()))
{
+if(debug) std::cerr found it value \n;
this-SetProperty(property, value);
}
else if(default_value)
{
+if(debug) std::cerr not found default_value \n;
this-SetProperty(property, default_value);
}
}
diff --git a/Source/cmTargetLinkLibrariesCommand.cxx b/Source/cmTargetLin
kLibrariesCommand.cxx
index 805959d..d2be3fa 100644
--- a/Source/cmTargetLinkLibrariesCommand.cxx
+++ b/Source/cmTargetLinkLibrariesCommand.cxx
@@ -219,6 +219,7 @@ cmTargetLinkLibrariesCommand::HandleLibrary(const cha
r* lib,
// Handle normal case first.
if(!this-DoingInterface)
{
+std::cerr this-Target-GetName() Not doing interface \
n;
this-Makefile
I ended up with this:
libA
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libB
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libC
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libB Not doing interface
libC Not doing interface
libC Not doing interface
Do you have other prints that I should add? How is this supposed to work?
-Bill
How exactly it works I am not entirely certain. I followed the suggestion in
this thread:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/1865/focus=1868
and it just worked for me.
I assume the contents of LINK_INTERFACE_LIBRARIES gets read somewhere else
to create the actual link line. each of libA libB and libC do not get added
to the link_interfaces, and using set(CMAKE_LINK_INTERFACE_LIBRARIES )
should be the same as using
target_link_libraries(libA LINK_INTERFACE_LIBRARIES )
for each library.
It works for me, but I don't know why it doesn't work for you. Maybe Brad
can have some insight?
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
On 10/12/2011 2:22 AM, Stephen Kelly wrote: using set(CMAKE_LINK_INTERFACE_LIBRARIES ) should be the same as using target_link_libraries(libA LINK_INTERFACE_LIBRARIES ) for each library. It is. The example under discussion has the same behavior even if you explicitly set it on each target. It works for me, but I don't know why it doesn't work for you. Maybe Brad can have some insight? The Modules/Platform/Darwin.cmake contains these lines: # Need to list dependent shared libraries on link line. When building # with -isysroot (for universal binaries), the linker always looks for # dependent libraries under the sysroot. Listing them on the link # line works around the problem. SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 1) which were added here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2cff26fa#patch1 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=82fcaebe#patch4 The behavior we are seeing in the test on Apple can be changed to the expected behavior by adding SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 0) to the CMakeLists.txt file. However, I don't remember the details of why I had to add that to Darwin.cmake in the first place. Hopefully there is a better fix for the original problem. -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
On Wed, Oct 12, 2011 at 10:30 AM, Stephen Kelly steve...@gmail.com wrote: Brad King wrote: On 10/12/2011 2:22 AM, Stephen Kelly wrote: using set(CMAKE_LINK_INTERFACE_LIBRARIES ) should be the same as using target_link_libraries(libA LINK_INTERFACE_LIBRARIES ) for each library. It is. The example under discussion has the same behavior even if you explicitly set it on each target. snip The behavior we are seeing in the test on Apple can be changed to the expected behavior by adding SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 0) to the CMakeLists.txt file. However, I don't remember the details of why I had to add that to Darwin.cmake in the first place. Hopefully there is a better fix for the original problem. 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 already grepped for CMAKE_LINK_DEPENDENT_LIBRARY_FILES and it seems to not appear anywhere else but Darwin.cmake. I remember the tests failing on freebsd and some windows too, so if you have any idea why that might be, I'd be interested to know. 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 $ git grep CMAKE_LINK_DEPENDENT_LIBRARY_FILES ChangeLog.txt:CMAKE_LINK_DEPENDENT_LIBRARY_FILES boolean. Modules/Platform/Darwin.cmake:SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 1) Source/cmComputeLinkInformation.cxx: if(this-Makefile-IsOn(CMAKE_LINK_DEPENDENT_LIBRARY_FILES)) Source/cmDocumentVariables.cxx: cm-DefineProperty(CMAKE_LINK_DEPENDENT_LIBRARY_FILES, The important occurrence would seem to be the one in Source/cmComputeLinkInformation.cxx... -- 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 10/12/2011 10:38 AM, David Cole wrote: On Wed, Oct 12, 2011 at 10:30 AM, Stephen Kellysteve...@gmail.com wrote: I already grepped for CMAKE_LINK_DEPENDENT_LIBRARY_FILES and it seems to not appear anywhere else but Darwin.cmake. I remember the tests failing on freebsd and some windows too, so if you have any idea why that might be, I'd be interested to know. $ git grep CMAKE_LINK_DEPENDENT_LIBRARY_FILES ChangeLog.txt:CMAKE_LINK_DEPENDENT_LIBRARY_FILES boolean. Modules/Platform/Darwin.cmake:SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 1) Source/cmComputeLinkInformation.cxx: if(this-Makefile-IsOn(CMAKE_LINK_DEPENDENT_LIBRARY_FILES)) Source/cmDocumentVariables.cxx: cm-DefineProperty(CMAKE_LINK_DEPENDENT_LIBRARY_FILES, The important occurrence would seem to be the one in Source/cmComputeLinkInformation.cxx... I think Steve meant that it does not appear in other platform info files. -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
On 10/11/2011 2:33 AM, Stephen Kelly wrote: Hi, I'm trying to find out why the target_link_libraries unit tests are failing on some platforms (but not mine...). I'm enabling one platform at a time. I enabled the failing tests for APPLE, so if you want to try it out, you need to comment out the if(APPLE). So, the test is still failing on the dashboard now right? I see it failed last night on all the macs, and on the continuous this morning. So, what do we need to comment out? Are you going to at least temporarily fix the dashboard test failures today? Did you mean to say if(NOT APPLE) maybe? The test output from these tests are very hard for me to parse: http://www.cdash.org/CDash/testDetails.php?test=118663911build=1614189 Something is failing but I have no idea what. Perhaps you could annotate the tests a bit more so that it prints out a test name or something. Testing link with CLEAR_LINK_INTERFACE_LIBRARIES=TRUE, SPECIFY_LINK_INTERFACE_LIBRARIES = TRUE test # 2. Or maybe even put a name into the expect_fail calls so that when it fails you can easily go back to the line in the CMakeLists.txt where the expect_fail is called.Maybe the test should print out the CMakeLists.txt file that was generated for it? So, in this case: http://www.cdash.org/CDash/testDetails.php?test=118663911build=1614189 What is it you can not see in your output? It looks to me that for each of them it is linking everything: /usr/bin/g++-4.2 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wunused -Wpointer-arith -Winvalid-pch -Wcast-align -Wdisabled-optimization -Wnewline-eof -fdiagnostics-show-option -Woverloaded-virtual -Wshadow -Wwrite-strings -g -fstack-protector-all -D_FORTIFY_SOURCE=2 -arch ppc -isysroot /Developer/SDKs/MacOSX10.5.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/exec.dir/main.cpp.o -o exec /Users/builder/kitware/CMake-gcc-dbg-ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibC.dylib /Users/builder/kitware/CMake-gcc-dbg-ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibA.dylib /Users/builder/kitware/CMake-gcc-dbg-ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibB.dylib If that is true, then the issue must be in the generator some how... However, I am not really sure if I am looking at the right link line Bottom line, can you make the test pass again, and what experiment do you want someone on a mac to do for you? -Bill -- 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
Bill Hoffman wrote: On 10/11/2011 2:33 AM, Stephen Kelly wrote: Hi, I'm trying to find out why the target_link_libraries unit tests are failing on some platforms (but not mine...). I'm enabling one platform at a time. I enabled the failing tests for APPLE, so if you want to try it out, you need to comment out the if(APPLE). So, the test is still failing on the dashboard now right? I see it failed last night on all the macs, and on the continuous this morning. So, what do we need to comment out? Are you going to at least temporarily fix the dashboard test failures today? Did you mean to say if(NOT APPLE) maybe? Nope, a few days ago it failed on more than just macs, it also failed on some windows and BSD, but I don't know why. Rather than make the whole dashboard light up, I only enabled the tests for APPLE first. I guess that once we find out why that does not work as expected, the fix will fix all other platforms too. The test output from these tests are very hard for me to parse: http://www.cdash.org/CDash/testDetails.php?test=118663911build=1614189 Something is failing but I have no idea what. Perhaps you could annotate the tests a bit more so that it prints out a test name or something. Testing link with CLEAR_LINK_INTERFACE_LIBRARIES=TRUE, SPECIFY_LINK_INTERFACE_LIBRARIES = TRUE test # 2. Or maybe even put a name into the expect_fail calls so that when it fails you can easily go back to the line in the CMakeLists.txt where the expect_fail is called.Maybe the test should print out the CMakeLists.txt file that was generated for it? I can look into doing these things. Seems like a good idea. So, in this case: http://www.cdash.org/CDash/testDetails.php?test=118663911build=1614189 What is it you can not see in your output? It looks to me that for each of them it is linking everything: /usr/bin/g++-4.2 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wunused -Wpointer-arith -Winvalid-pch -Wcast-align -Wdisabled-optimization -Wnewline-eof -fdiagnostics-show-option -Woverloaded-virtual -Wshadow -Wwrite-strings -g -fstack-protector-all -D_FORTIFY_SOURCE=2 -arch ppc -isysroot /Developer/SDKs/MacOSX10.5.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/exec.dir/main.cpp.o -o exec /Users/builder/kitware/CMake-gcc-dbg- ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibC.dylib /Users/builder/kitware/CMake-gcc-dbg- ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibA.dylib /Users/builder/kitware/CMake-gcc-dbg- ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibB.dylib If that is true, then the issue must be in the generator some how... It indeed looks like it is linking against everything, but it should not be. However, I am not really sure if I am looking at the right link line I think you are. Bottom line, can you make the test pass again, and what experiment do you want someone on a mac to do for you? I have attached a tarball. For me it fails when linking the executable. CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' This is the expected result because I have used set(CMAKE_LINK_INTERFACE_LIBRARIES ) It should work on all platforms as far as I know. Commenting out the test would make it look like the feature works, though it does not work on APPLE and maybe others. If that builds on APPLE for you, please check why the line in cmTarget.cxx: this-SetPropertyDefault(LINK_INTERFACE_LIBRARIES, 0); introduced in commit ac4dd41bcc3818f010fc19e28b2e76e2407d2a09 is not having the desired effect on APPLE. Thanks, Steve. build_should_fail.tar.gz Description: application/compressed-tar -- 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
So, basically we this:
set(CMAKE_LINK_INTERFACE_LIBRARIES )
add_library(libA SHARED classA.cpp)
add_library(libB SHARED classB.cpp)
add_library(libC SHARED classC.cpp)
generate_export_header(libA)
generate_export_header(libB)
generate_export_header(libC)
target_link_libraries(libB libA)
target_link_libraries(libC libA libB)
add_executable(exec
main.cpp
)
target_link_libraries(exec libC )
So, setting CMAKE_LINK_INTERFACE_LIBRARIES to is supposed to make the
transitive linking of A and B not happen when linking C. I tried adding
some print stuff in the code. But, I am not sure where to look.
I added the following:
void cmTarget::SetPropertyDefault(const char* property,
const char* default_value)
{
+ bool debug = false;
+ if(strcmp(LINK_INTERFACE_LIBRARIES, property) == 0)
+debug = true;
+ if(debug) std::cerr this-GetName() \n;
// Compute the name of the variable holding the default value.
std::string var = CMAKE_;
var += property;
-
+ if(debug) std::cerr var \n;
if(const char* value = this-Makefile-GetDefinition(var.c_str()))
{
+if(debug) std::cerr found it value \n;
this-SetProperty(property, value);
}
else if(default_value)
{
+if(debug) std::cerr not found default_value \n;
this-SetProperty(property, default_value);
}
}
diff --git a/Source/cmTargetLinkLibrariesCommand.cxx b/Source/cmTargetLin
kLibrariesCommand.cxx
index 805959d..d2be3fa 100644
--- a/Source/cmTargetLinkLibrariesCommand.cxx
+++ b/Source/cmTargetLinkLibrariesCommand.cxx
@@ -219,6 +219,7 @@ cmTargetLinkLibrariesCommand::HandleLibrary(const cha
r* lib,
// Handle normal case first.
if(!this-DoingInterface)
{
+std::cerr this-Target-GetName() Not doing interface \
n;
this-Makefile
I ended up with this:
libA
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libB
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libC
CMAKE_LINK_INTERFACE_LIBRARIES
found it
libB Not doing interface
libC Not doing interface
libC Not doing interface
Do you have other prints that I should add? How is this supposed to work?
-Bill
--
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
