Re: [cmake-developers] CXX_STANDARD and linking

[CHEVRIER, Marc]

No problem for me to keep broken behavior of SolarisStudio.
Let me know when C++ Standard support including linking part is implemented, I 
can help you to validate it on Solaris SPARC.

Thanks.

Marc




On 08/10/15 19:24, "cmake-developers on behalf of Brad King" 
 wrote:

>On 10/08/2015 11:38 AM, Brad King wrote:
>> On 10/07/2015 03:22 PM, Stephen Kelly wrote:
>>> The CMake 3.3 behavior of this is the same as it has always been since 
>>> introducing compile-features for SolarisStudio. 
>> 
>> Well that behavior was broken.  We never had a nightly dashboard for it.
>> Now I got nightly testing set up and it fails many tests without my changes.
>
>OTOH I should not have rushed in this change for 3.4.  We can just let
>it act as 3.3 did and no one will be worse off.  Then we can pick this
>up in post-3.4 development.  Reverted for now:
>
> Revert topic 'compiler-features-solaris'
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=340d0897
>
>I've scheduled this for the 'release' branch for 3.4.0-rc2.
>
>-Brad
>
>-- 
>
>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
-- 

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

Re: [cmake-developers] CXX_STANDARD and linking

[Brad King]

On 10/08/2015 11:38 AM, Brad King wrote:
> On 10/07/2015 03:22 PM, Stephen Kelly wrote:
>> The CMake 3.3 behavior of this is the same as it has always been since 
>> introducing compile-features for SolarisStudio. 
> 
> Well that behavior was broken.  We never had a nightly dashboard for it.
> Now I got nightly testing set up and it fails many tests without my changes.

OTOH I should not have rushed in this change for 3.4.  We can just let
it act as 3.3 did and no one will be worse off.  Then we can pick this
up in post-3.4 development.  Reverted for now:

 Revert topic 'compiler-features-solaris'
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=340d0897

I've scheduled this for the 'release' branch for 3.4.0-rc2.

-Brad

-- 

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

Re: [cmake-developers] CXX_STANDARD and linking

[Stephen Kelly]

Brad King wrote:

> 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.

Just some more on this:

The CMake 3.3 behavior of this is the same as it has always been since 
introducing compile-features for SolarisStudio. 

Any users aware that compile-features only affect compilation will have 
added the link flag themselves with one of the already available mechanims. 
Such users will be affected by this CMake 3.4 change.

For the build of CMake itself on Solaris, we should probably add the 
required link flag until there is a porcelian feature for it (in 
CompileFlags.cmake?).

I'm also not confident in commit v3.4.0-rc1~10^2~1 (Features: Fix C++98 
flags on Oracle SolarisStudio 12.4 on Linux, 2015-09-30) because it will 
mean that 'c++98 mode' on Solaris 12.4 is forced to use libstdc++ instead of 
stlport4 or libCstd (rougewave). I'm not sure of the implications of that.

So, it might be best to revert that commit and its parent.

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

Re: [cmake-developers] CXX_STANDARD and linking

[Brad King]

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.  It is conflated with a bug fix because the link flags
are needed to support existing features on Solaris.

> 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 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.

> 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,").  Also they need
to be selected by CMake rather than propagated as a flag specified
by project code.

> 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?
In that case we will certainly need more sophisticated logic for
selecting the link flag.

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

Thanks,
-Brad

-- 

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

Re: [cmake-developers] CXX_STANDARD and linking

[Ben Boeckel]

On Sun, Oct 04, 2015 at 16:47:40 +0200, Stephen Kelly wrote:
> The existing CMake feature deals with compilation, but does not deal with 
> linking. 

A generic target_link_options() is necessary for other things as well,
such as:

  * -fsanitize=address needs to be passed to the linker to add -lasan
(similar for other sanitizers);
  * -pg -ftest-coverage -fprofile-arcs needs to be passed to the
linker for adding profiling information.

--Ben
-- 

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

Re: [cmake-developers] CXX_STANDARD and linking

[Stephen Kelly]

Brad King wrote:

> On 09/28/2015 03:20 PM, Brad King wrote:
>> for now we should look at turning off all language standard and
>> compile feature support for SolarisStudio when not hosted on Linux.
> 
> Done here:
> 
>  Features: Disable support for Oracle SolarisStudio on non-Linux
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61bc0f73
> 
>  Tests: Suppress WriteCompilerDetectionHeader failure on SunPro
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fdf7594
> 
> I also made a fix for Linux:
> 
>  Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c824b23d
> 
> Steve, please review these changes.

Thanks, I've put some thought into this now.

The existing CMake feature deals with compilation, but does not deal with 
linking. 

We pass -std=foo when compiling but not when linking. In the case of GNU and 
Clang, this works because the standard library binary is the same regardless 
of that flag. I did some experiements, and 

* passing no -std flag
* passing -std=c++11
* passing -std=gnu++11

each resulted in invoking collect2 or ld with identical parameters for GNU 
and Clang in respective situations.

For Solaris, the situation is different. My understanding of standard 
libraries there is summarized here:

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c69ec6f

Namely, we can pass -std=c++03 or -std=c++11 in the the compile step to use 
specific dialect features for compilation, but to specify the 
appropriate/corresponding standard library (the GNU one) we also need to 
specify one of those flags at link time.

Currently cmake has no feature for specifying flags to use at link time for 
a particular standard library. This missing feature is also apparent when 
noting that we can specify a particular standard library to Clang by using 
the -stdlib=libc++ or -stdlib=libstdc++ flags. Using GNU we can specify the 
flag -nodefaultlibs to avoid automatic linking with libstdc++ and then 
specify additional flags to compile and link to libc++ if we wish.

This is the same missing feature whether talking about SolarisStudio, GNU, 
or Clang.

I think the current state is that CMake-compile-features can work with 
SolarisStudio to specify compile flags, but CMake currently has no feature 
for inferring link flags as a result of that. That is, the responsibility 
for specifying the link flags remains with the user for now. 

So, is this thread really about a bug, or is it a feature request? 

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. When testing the compiler on linux, 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

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. 

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.

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

Re: [cmake-developers] CXX_STANDARD and linking

[Brad King]

On 09/28/2015 03:20 PM, Brad King wrote:
> for now we should look at turning off all language standard and
> compile feature support for SolarisStudio when not hosted on Linux.

Done here:

 Features: Disable support for Oracle SolarisStudio on non-Linux
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61bc0f73

 Tests: Suppress WriteCompilerDetectionHeader failure on SunPro
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fdf7594

I also made a fix for Linux:

 Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c824b23d

Steve, please review these changes.

Thanks,
-Brad
-- 

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

Re: [cmake-developers] CXX_STANDARD and linking

[CHEVRIER, Marc]

Seems OK for me… But my personal situation is even worst now! :)

The situation evolved from a buggy support of C++11 on Solaris to no support at 
all. Do you have any idea (and schedule) for re-introduction of this feature, 
knowing that the key point is the lack of propagating of c++11 compile option 
to the link command. 

Thank you for your help.

Marc




On 30/09/15 16:01, "Brad King"  wrote:

>On 09/28/2015 03:20 PM, Brad King wrote:
>> for now we should look at turning off all language standard and
>> compile feature support for SolarisStudio when not hosted on Linux.
>
>Done here:
>
> Features: Disable support for Oracle SolarisStudio on non-Linux
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61bc0f73
>
> Tests: Suppress WriteCompilerDetectionHeader failure on SunPro
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fdf7594
>
>I also made a fix for Linux:
>
> Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c824b23d
>
>Steve, please review these changes.
>
>Thanks,
>-Brad
-- 

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

Re: [cmake-developers] CXX_STANDARD and linking

[CHEVRIER, Marc]

On Solaris, activating C++11 standard switch the compiler into a completely 
different mode:
* Mangling is different
* C++ runtime is the GNU one, delivered as part of SolarisStudio 12.4 (Sun C++ 
runtime is no longer supported)

This is why the flag -std=c++11 must be passed to the link step to enable 
compiler to select the correct runtime…

Marc




On 28/09/15 21:20, "cmake-developers on behalf of Brad King" 
 wrote:

>On 09/28/2015 02:34 PM, Stephen Kelly wrote:
>>> Steve?  According to cmake-compile-features(7) you tested this with
>>> Oracle SolarisStudio version 12.4.
>> 
>> Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps 
>> that's a relevant difference from 'real' Solaris.
>
>That seems to be the case.  The interaction with C++ runtime library
>selection may differ.
>
>Although we had dashboard builds for SolarisStudio 12.3 on SunOS the
>compiler feature/standard logic is enabled only for SunPro 5.13 and
>above which do not appear until SolarisStudio 12.4.
>
>On 09/28/2015 01:42 PM, Brad King wrote:
>> The logic in cmLocalGenerator::AddCompileOptions that selects the final
>> _STANDARD level and adds a flag for it may need to be factored
>> out into a separate step (in Compute?) that selects the level.  Then
>> AddCompileOptions can continue to add the compiler flag and we'll need
>> new code to add link-time compiler-driver flags based on the selected
>> standard level.
>
>Steve, does using _STANDARD to put -std= flags on the link line
>seem like the right approach to fix this?
>
>This won't be done before CMake 3.4 so for now we should look at
>turning off all language standard and compile feature support for
>SolarisStudio when not hosted on Linux.
>
>Thanks,
>-Brad
>-- 
>
>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
-- 

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

Re: [cmake-developers] CXX_STANDARD and linking

[Stephen Kelly]

Brad King wrote:

> On 09/28/2015 03:55 AM, CHEVRIER, Marc wrote:
>> Anyway, the main problem is the fact that, currently, C++ standard
>> handling is not usable on Solaris. Do have any plan to fix this problem
>> anytime soon?
>> 
>> On 25/09/15 17:24, "Brad King" wrote:
>>> Compiling with a -std= flag should link with such a flag too.
>>> Flags like this are why CMake has always passed CMAKE_CXX_FLAGS
>>> to the C++ compiler when using it to drive the linker.  This does
>>> not appear to be the case anywhere right now when the flag is added
>>> via CXX_STANDARD.
> 
> Steve?  According to cmake-compile-features(7) you tested this with
> Oracle SolarisStudio version 12.4.  However, our dashboard covered
> only up through 12.3.

Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps 
that's a relevant difference from 'real' Solaris.

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

Re: [cmake-developers] CXX_STANDARD and linking

[Brad King]

On 09/28/2015 02:34 PM, Stephen Kelly wrote:
>> Steve?  According to cmake-compile-features(7) you tested this with
>> Oracle SolarisStudio version 12.4.
> 
> Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps 
> that's a relevant difference from 'real' Solaris.

That seems to be the case.  The interaction with C++ runtime library
selection may differ.

Although we had dashboard builds for SolarisStudio 12.3 on SunOS the
compiler feature/standard logic is enabled only for SunPro 5.13 and
above which do not appear until SolarisStudio 12.4.

On 09/28/2015 01:42 PM, Brad King wrote:
> The logic in cmLocalGenerator::AddCompileOptions that selects the final
> _STANDARD level and adds a flag for it may need to be factored
> out into a separate step (in Compute?) that selects the level.  Then
> AddCompileOptions can continue to add the compiler flag and we'll need
> new code to add link-time compiler-driver flags based on the selected
> standard level.

Steve, does using _STANDARD to put -std= flags on the link line
seem like the right approach to fix this?

This won't be done before CMake 3.4 so for now we should look at
turning off all language standard and compile feature support for
SolarisStudio when not hosted on Linux.

Thanks,
-Brad
-- 

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

Re: [cmake-developers] CXX_STANDARD and linking

[Brad King]

On 09/28/2015 03:55 AM, CHEVRIER, Marc wrote:
> Anyway, the main problem is the fact that, currently, C++ standard handling
> is not usable on Solaris. Do have any plan to fix this problem anytime soon?
> 
> On 25/09/15 17:24, "Brad King" wrote:
>> Compiling with a -std= flag should link with such a flag too.
>> Flags like this are why CMake has always passed CMAKE_CXX_FLAGS
>> to the C++ compiler when using it to drive the linker.  This does
>> not appear to be the case anywhere right now when the flag is added
>> via CXX_STANDARD.

Steve?  According to cmake-compile-features(7) you tested this with
Oracle SolarisStudio version 12.4.  However, our dashboard covered
only up through 12.3.

The logic in cmLocalGenerator::AddCompileOptions that selects the final
_STANDARD level and adds a flag for it may need to be factored
out into a separate step (in Compute?) that selects the level.  Then
AddCompileOptions can continue to add the compiler flag and we'll need
new code to add link-time compiler-driver flags based on the selected
standard level.

Thanks,
-Brad
-- 

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

Re: [cmake-developers] CXX_STANDARD and linking (was: C++11 support broken for SolarisStudio 12.4)

[CHEVRIER, Marc]

Hi,

Bootstrapping CMake with the flags you specify and SOlarisStudio 12.4 enable to 
generate a usable Cmake but some tests are failing with error related to CXX 
standard.
For example, test 32, CompileFeatures generates error:
32: CMake Error: Error required internal CMake variable not set, cmake may be 
not be built correctly.
32: Missing variable is:
32: CMAKE_CXX98_EXTENSION_COMPILE_OPTION

In the meantime, I am using SolarisStudio 12.2 for CMake bootstrapping.

Anyway, the main problem is the fact that, currently, C++ standard handling is 
not usable on Solaris. Do have any plan to fix this problem anytime soon?


After this problem fixed, I hope CMake bootstrapping will be solved as well…

Thank you for your help.

Marc


On 25/09/15 17:24, "Brad King"  wrote:

>Steve,
>
>On 09/25/2015 03:58 AM, CHEVRIER, Marc wrote:
>> * If I add option -std=c++11 in the file .../Test.dir/link.txt,
>>   link is successful 
>
>Compiling with a -std= flag should link with such a flag too.
>Flags like this are why CMake has always passed CMAKE_CXX_FLAGS
>to the C++ compiler when using it to drive the linker.  This does
>not appear to be the case anywhere right now when the flag is added
>via CXX_STANDARD.
>
>Marc, meanwhile you should be able to bootstrap CMake with
>
> bootstrap ... -- -DCMake_NO_C_STANDARD=1 -DCMake_NO_CXX_STANDARD
>
>to skip trying to use any -std= flags.
>
>-Brad
>
-- 

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

Re: [cmake-developers] CXX_STANDARD and linking (was: C++11 support broken for SolarisStudio 12.4)

[Brad King]

Steve,

On 09/25/2015 03:58 AM, CHEVRIER, Marc wrote:
> * If I add option -std=c++11 in the file .../Test.dir/link.txt,
>   link is successful 

Compiling with a -std= flag should link with such a flag too.
Flags like this are why CMake has always passed CMAKE_CXX_FLAGS
to the C++ compiler when using it to drive the linker.  This does
not appear to be the case anywhere right now when the flag is added
via CXX_STANDARD.

Marc, meanwhile you should be able to bootstrap CMake with

 bootstrap ... -- -DCMake_NO_C_STANDARD=1 -DCMake_NO_CXX_STANDARD

to skip trying to use any -std= flags.

-Brad

-- 

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