[CMake] How is the linker language of a library determined?

Robin Verschueren robin.verschueren at gmail.com
Wed Nov 8 02:40:44 EST 2017


I use the "Unix Makefiles" generator (on macOS), with clang and clang++ as
compilers (XCode version 9).

On Wed, 8 Nov 2017 at 03:47 Craig Scott <craig.scott at crascit.com> wrote:

>
> On Wed, Nov 8, 2017 at 7:29 AM, Robin Verschueren <
> robin.verschueren at gmail.com> wrote:
>
>> Hi there,
>>
>> I'm building some C code into a library. The library needs to link to a
>> C++ static library (IMPORTED target). I'm puzzled by the following:
>>
>>    - with BUILD_SHARED_LIBS=OFF (default), everything works as expected
>>    and CMake sees the C library as a "C++ library" (i.e. it uses the C++
>>    compiler/linker to link the two libraries together into a static library).
>>    - with BUILD_SHARED_LIBS=ON however, CMake tries to link the C
>>    library to the C++ library with cc (clang in my case), and I get linker
>>    errors.
>>
>> My questions:
>>
>> *What mechanism does CMake use to determine the linker language, and why
>> is it different in these two cases?* Is it because I want to link a
>> shared library against a static library as opposed to two static ones? Or
>> is BUILD_SHARED_LIBS a red herring? Does CMake have a notion of what linker
>> language to use for IMPORTED targets?
>>
>>
> Can you confirm which CMake generator type you are using? If it is the
> Xcode generator, do you get the same behaviour building at the command line
> as you do from within the IDE? I only ask because your symptoms sound
> eerily familiar to a problem I've seen before where linking used a
> different launcher from the command line compared to the IDE (see the Xcode
> section of this article
> <https://crascit.com/2016/04/09/using-ccache-with-cmake/>).
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171108/8591ae2c/attachment.html>


More information about the CMake mailing list