[cmake-developers] CXX_STANDARD and linking

[Stephen Kelly]

Brad King wrote:

> On 10/04/2015 10:47 AM, Stephen Kelly wrote:
>> So, is this thread really about a bug, or is it a feature request?
> 
> I think it has become a feature request to select link flags for language
> standard levels.  

Not the language standard level, but the standard library to compile with 
and link with. 

It just happens that the way to link to the correct library on SolarisStudio 
is -std=c++11 (or -std=c++03 which presumably also links to the same 
libstdc++.so shipped with SolarisStudio; but I just note this for 
completeness). Also, I agree that we should pass -std=c++11 when linking 
with GNU too, which is why it looks like 'language standard level', but it 
is not because the language has no relevance at link time.

>> Perhaps those commits should be reverted. I see no reason for
>> SolarisStudio on linux to behave any differently than on solaris, so the
>> commit relating to that is probably not appropriate.
> 
> I don't want CMake to generate broken builds by default.  We *know* it
> goes wrong on Solaris and cannot possibly work without user intervention.
> If a problem comes up on Linux too we can deal with it as necessary.

I'm pretty sure the situation on linux is the same as on Solaris.

Stephen Kelly wrote:
> It is possible that I was operating as if the link flags were user
> responsibility and had configured my environment accordingly (though I
> don't remember).



>> I wrote here some ideas of a design for specifying the standard library
>> to use:
>> 
>>  
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284/focus=13296
> 
> Is that the right link?  I don't see discussion of -stdlib= in that
> message.

Gmane is not currently resolving the link. You might be right that there is 
no mention of -stdlib= flags, but I think there is mention of CMake 
providing IMPORTED targets which supply INTERFACE_ properties. I was 
referring to the design of cmake providing such IMPORTED targets, and indeed 
that design should allow the user to specify the library to link with, and 
that should add -stdlib= flags where appropriate.

>> Perhaps, rather than passing CMAKE_CXX11_EXTENSION_COMPILE_OPTION to the
>> linker, we should work more on a design like the above way to specify a
>> standard library.
> 
> Yes, but the -std= and -stdlib= flags are different from the full
> LINK_OPTIONS discussion because they are meant specifically for the
> front end and not for the linker (never "-Wl,").  

Yes, I think previous design discussion (possibly the one linked above) 
included a TOOLCHAIN_OPTIONS property for cases like this and -pthread etc.

> Also they need
> to be selected by CMake rather than propagated as a flag specified
> by project code.

Yes, or some combination of both being possible.

>> The compile features can imply a default and a set of allowed
>> alternatives (for example, compiling with cxx_static_assert implies the
>> use of stdlibc++ or libc++ with Clang by default but there is a way to
>> use the other
>> instead).  The COMPATIBLE_INTERFACE features may also be used to ensure
>> that targets which link together all use the same standard library.
> 
> Originally I was thinking we should just use the same -std= for linking
> that we do for compilation, but don't we currently support compiling
> different targets at different standard levels and then linking them?

As I wrote, this is not about 'linking with a language standard level', 
which is not a concept which has meaning.  This is about 'which standard 
library binary do we link to?'. In the case of GNU, we link to libstdc++.so. 

If we would link some targets to libstdc++ and others to libc++ we could not 
use them together because the standard library implementations are not 
binary compatibile with each other.  See also what I wrote before about 
using COMPATIBLE_INTERFACE properties to diagnose this at cmake time.

> BTW, I noticed in cmLocalGenerator::AddCompileOptions that we currently
> mutate the configure step result by setting target properties like
> <LANG>_STANDARD during generation.  Also, this is done with one "config"
> value which may not be appropriate in multi-config generators.

Interesting. I've filed a bug here:

 http://public.kitware.com/Bug/view.php?id=15773

Thanks,

Steve.