[cmake-developers] setting LINKER_LANGUAGE still adds -lstdc++

[James Bigler]

On Mon, Oct 8, 2012 at 10:40 PM, James Bigler <jamesbigler at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20121008/13e9e23e/attachment.html>