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. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers