On Mon, Oct 8, 2012 at 10:40 PM, James Bigler <jamesbig...@gmail.com> wrote:
> In my project I need to manually link against a special version of > libstdc++, so I manually set the target link language to C and then add my > special library to the link line. On Linux this seems to work just fine, > but on OSX it still add -lstdc++ to the link like. Here's my cmake code: > > cmake_minimum_required(VERSION 2.8) > project(linking_fun) > > add_library(a SHARED a.cpp) > set_target_properties(a PROPERTIES LINKER_LANGUAGE "C") > > add_library(b SHARED b.c) > > a.cpp and b.c both simply have 'int foo() { return 3;}' > > > And here's the compiler output which has the -lstdc++ on the link line for > library a, but not for library b. > > Linking C shared library liba.dylib > /opt/local/bin/cmake -E cmake_link_script CMakeFiles/a.dir/link.txt > --verbose=1 > /usr/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -o > liba.dylib -install_name > /Users/jbigler/code/temp/cmake/static-libstdcpp/liba.dylib > CMakeFiles/a.dir/a.cpp.o > -lstdc++/usr/bin/../lib/clang/4.0/lib/darwin/libclang_rt.osx.a > /opt/local/bin/cmake -E cmake_progress_report > /Users/jbigler/code/temp/cmake/static-libstdcpp/CMakeFiles 1 > [ 50%] Built target a > make -f CMakeFiles/b.dir/build.make CMakeFiles/b.dir/depend > cd /Users/jbigler/code/temp/cmake/static-libstdcpp && > /opt/local/bin/cmake -E cmake_depends "Unix Makefiles" > /Users/jbigler/code/temp/cmake/static-libstdcpp > /Users/jbigler/code/temp/cmake/static-libstdcpp > /Users/jbigler/code/temp/cmake/static-libstdcpp > /Users/jbigler/code/temp/cmake/static-libstdcpp > /Users/jbigler/code/temp/cmake/static-libstdcpp/CMakeFiles/b.dir/DependInfo.cmake > --color= > make -f CMakeFiles/b.dir/build.make CMakeFiles/b.dir/build > Linking C shared library libb.dylib > /opt/local/bin/cmake -E cmake_link_script CMakeFiles/b.dir/link.txt > --verbose=1 > /usr/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -o > libb.dylib -install_name > /Users/jbigler/code/temp/cmake/static-libstdcpp/libb.dylib > CMakeFiles/b.dir/b.c.o > > Is this a bug or a "feature"? > > James > I spent some time in the debugger to try and understand why CMake is making the decisions it is. It comes down to this function which loops over all the LinkClosures and calls AddImplicitLinkInfo for all languages that *don't* match the language of the target. //---------------------------------------------------------------------------- void cmComputeLinkInformation::AddImplicitLinkInfo() { // The link closure lists all languages whose implicit info is needed. cmTarget::LinkClosure const* lc=this->Target->GetLinkClosure(this->Config); for(std::vector<std::string>::const_iterator li = lc->Languages.begin(); li != lc->Languages.end(); ++li) { // Skip those of the linker language. They are implicit. if(*li != this->LinkLanguage) { this->AddImplicitLinkInfo(*li); } } } The LinkClosure is computed and the only language in it is CXX due to the CXX-ness of the input sources. I'm not sure what to think about this. I told CMake to link the target as if it were a C target, then it decides that it needs CXX libraries because it found CXX sources in my library. If I go through the trouble of specifying that I want to link the library as if it were C, why do the source files get to override my property? It also seems to me that the source file language should only guide the link language when the user didn't specify it explicitly. James
-- 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://www.cmake.org/mailman/listinfo/cmake