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
[cmake-developers] [CMake 0012515]: FindDCMTK does not determine and report complete external library dependencies
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12515 == Reported By:Torsten Rohlfing Assigned To: == Project:CMake Issue ID: 12515 Category: Modules Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-10-11 17:25 EDT Last Modified: 2011-10-11 17:25 EDT == Summary:FindDCMTK does not determine and report complete external library dependencies Description: When using FindDCMTK to configure the use of the DCMTK DICOM toolkit, external library dependencies are not detected. These, therefore, have to be added by user projects in a non-portable way. Examples: On Fedora (f15), we need the "png tiff CharLS xml2 ssl z" libraries to resolve DCMTK's dependencies. Steps to Reproduce: Extract files from attached tgz archive: CMakeLists.txt; example.cxx Run "cmake .; make" Result: [torsten@axon dcmtk]$ make Scanning dependencies of target example [100%] Building CXX object CMakeFiles/example.dir/example.cxx.o Linking CXX executable example /usr/lib64/dcmtk/libdcmtls.so: undefined reference to `SSL_CTX_free' /usr/lib64/dcmtk/libdcmsr.so: undefined reference to `xmlSchemaSetParserErrors' /usr/lib64/dcmtk/libdcmdata.so: undefined reference to `deflateInit2_' /usr/lib64/dcmtk/libdcmtls.so: undefined reference to `SSL_CIPHER_get_bits' /usr/lib64/dcmtk/libdcmimage.so: undefined reference to `png_create_info_struct' and so forth... == Issue History Date ModifiedUsername FieldChange == 2011-10-11 17:25 Torsten RohlfingNew Issue 2011-10-11 17:25 Torsten RohlfingFile Added: dcmtk-depends.tgz == -- 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
[cmake-developers] [CMake 0012514]: Objective-C files compile as C++ language
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12514 == Reported By:AerialX Assigned To: == Project:CMake Issue ID: 12514 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-10-11 16:36 EDT Last Modified: 2011-10-11 16:36 EDT == Summary:Objective-C files compile as C++ language Description: CMAKE_CXX_SOURCE_FILE_EXTENSIONS defaults to including both the .mm and .m extensions. While .mm is indeed used for Objective-C++, .m is Objective-C and should be moved into CMAKE_C_SOURCE_FILE_EXTENSIONS instead. As it is not currently possible to change these variables as a user or in a toolchain file, the only workaround is to manually mark your .m files as C language with set_source_files_properties. == Issue History Date ModifiedUsername FieldChange == 2011-10-11 16:36 AerialXNew Issue == -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
I am running your test right now... I do get these warnings: CMake Warning at /Users/kitware/bill/cmake/Modules/GenerateExportHeader.cmake:178 (message): GCC version older than 4.2 Call Stack (most recent call first): /Users/kitware/bill/cmake/Modules/GenerateExportHeader.cmake:348 (_test_compiler_hidden_visibility) lib/CMakeLists.txt:19 (generate_export_header) CMake Warning at /Users/kitware/bill/cmake/Modules/GenerateExportHeader.cmake:178 (message): GCC version older than 4.2 Call Stack (most recent call first): /Users/kitware/bill/cmake/Modules/GenerateExportHeader.cmake:348 (_test_compiler_hidden_visibility) lib/CMakeLists.txt:20 (generate_export_header) CMake Warning at /Users/kitware/bill/cmake/Modules/GenerateExportHeader.cmake:178 (message): GCC version older than 4.2 Call Stack (most recent call first): /Users/kitware/bill/cmake/Modules/GenerateExportHeader.cmake:348 (_test_compiler_hidden_visibility) lib/CMakeLists.txt:21 (generate_export_header) Does that have anything to do with this? Here is the link line: /usr/bin/c++-I/Users/kitware/bill/t/test19-b -I/Users/kitware/bill/t/test19 -I/Users/kitware/bill/t/test19/lib -I/Users/kitware/bill/t/test19-b/lib-o CMakeFiles/exec.dir/main.cpp.o -c /Users/kitware/bill/t/test19/main.cpp Linking CXX executable exec /Users/kitware/bill/CMake-gcc/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/bin/c++-Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/exec.dir/main.cpp.o -o exec lib/liblibC.dylib lib/liblibB.dylib lib/liblibA.dylib Do you have a suggestion of where to put some mark up in cmTarget.cxx or other places in the code to see where this is coming from? -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=118663911&build=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=118663911&build=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
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=118663911&build=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=118663911&build=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
[cmake-developers] [CMake 0012511]: Cmake doesn't fully optimize Release builds on Clang
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12511 == Reported By:bmn Assigned To: == Project:CMake Issue ID: 12511 Category: (No Category) Reproducibility:always Severity: major Priority: low Status: new == Date Submitted: 2011-10-11 03:25 EDT Last Modified: 2011-10-11 03:25 EDT == Summary:Cmake doesn't fully optimize Release builds on Clang Description: It uses -O3 flag, while the highest level is -O4 == Issue History Date ModifiedUsername FieldChange == 2011-10-11 03:25 bmnNew Issue == -- 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
