Cannot find a c compiler that supports both c 11 and the specified c flags

Installation issue: cmake #13227

Comments

pibion commented Oct 16, 2019 •

Steps to reproduce the issue

Platform and user environment

I am running a centos7 docker container, with gcc@4.8.5 installed on the system:

I’m confused by this error; I thought that a gcc version greater than 4.8.1 should implement the full C++11 standard.

Additional information

It seems that my spack installation is able to build some packages correctly:

Rebuilding the package with the following options also fails and produces spack-cc-cmake-n32j6id.in.log and spack-cc-cmake-n32j6id.out.log, both of which are attached below.

The text was updated successfully, but these errors were encountered:

chuckatkins commented Oct 18, 2019

I thought that a gcc version greater than 4.8.1 should implement the full C++11 standard.

Can you post the spack-src/Bootstrap.cmk/cmake_bootstrap.log from the failed build stage?

pibion commented Oct 19, 2019 •

Okay, good to know about gcc 4.8.5. I’ve attached the spack-src/Bootstrap.cmk/cmake_bootstrap.log below.

I’m running spack in a centos7 docker container, in case that helps:

pat-s commented Oct 25, 2019 •

I am getting the same error when using gcc@9.2.0 on CentOS7 (build from systems gcc@4.8.5).

Works when using gcc@4.8.5.

chuckatkins commented Oct 29, 2019

@pibion I just realized you’re missing the c++ and fortran compilers from your docker image. I believe that may be the cause here. Try changing:

Fun fact though, while tracking this down with @bradking we found an unrelated bug in the bootstrap script 😀

Unable to build cmake #117

Comments

ZachBacon commented May 6, 2020

Seems that I’m having some difficulty trying to bootstrap on msys2 with llvm-clang that I just built from master. I’ve tried everything from no flags to implying CC and CXX and then using these flags

however it seems that cmake’s bootstrap can’t seem figure out if clang supports c++11 or not.
cmake_bootstrap.log

The text was updated successfully, but these errors were encountered:

mstorsjo commented May 6, 2020

Seems that I’m having some difficulty trying to bootstrap on msys2 with llvm-clang that I just built from master. I’ve tried everything from no flags to implying CC and CXX and then using these flags

ZachBacon commented May 6, 2020 •

Yeah you’re right about that, I’m half awake. Barely enough coffee in me. However

For some reason though, it still doesn’t seem to pick up on the fact clang does support c++11.
Though it could be a simple case of cmake not understanding llvm-mingw clang and msys2 pairing.

mstorsjo commented May 6, 2020

ZachBacon commented May 6, 2020

mati865 commented May 6, 2020 •

Never mind the error is: error while loading shared libraries: api-ms-win-crt-locale-l1-1-0.dll: cannot open shared object file: No such file or directory

ZachBacon commented May 6, 2020

Most likely a side effect of having clang/mingw link to UCRT then? Suppose all I need to do is have the compiler find those files in path.

mstorsjo commented May 6, 2020

If the UCRT is installed system wide, that DLL should be found.. or did you just have the UCRT DLLs dropped into the compiler directory (or not at all, if llvm-mingw itself has been built in msys2)?

ZachBacon commented May 6, 2020

I just probably need to install the UCRT runtime most likely, I’m dealing with a fresh install of windows 10 at the moment.

mstorsjo commented May 6, 2020

ZachBacon commented May 6, 2020

perhaps msys2 is doing something in regards to the path.

My one guess is that msys2 only cares about certain parts of windows path, preventing anything built with the UCRT from finding the platform files.

mati865 commented May 6, 2020

Out of curiosity I’ve just checked my Win 10 box:

ZachBacon commented May 6, 2020

Looks like I’ll need to get my own copy of the UCRT and just set it in a path location.

ZachBacon commented May 6, 2020

Or just install a visual studio runtime.

mstorsjo commented May 6, 2020

Out of curiosity I’ve just checked my Win 10 box:

I just tried it out on MSYS2 here:

ZachBacon commented May 6, 2020

And yet trying to compile cmake from source is still having some issues.

mstorsjo commented May 6, 2020

And yet trying to compile cmake from source is still having some issues.

ZachBacon commented May 6, 2020

I will in a moment, trying out a test of my own.

ZachBacon commented May 6, 2020

Yeah it works just fine. Compiling a simple hello world test just runs both in msys2 and cmd and even powershell

mstorsjo commented May 6, 2020

Oh, I have a guess on what might be going wrong.

ZachBacon commented May 6, 2020

So far it seems to be doing the trick, it’s configuring properly now so far, I’ll update you if it completes, and if it does, if it compiles at all.

Installation Issue: CMake with Intel #15901

Comments

keltonhalbert commented Apr 6, 2020 •

I was trying to install and compile the H5Z-ZFP package, and it seems to have crashed with CMake. The issues with CMake can be replicated below, and the relevant error messages are attached. Any ideas on what’s going on here?

Spack version

Steps to reproduce the issue

Platform and user environment

General information

The text was updated successfully, but these errors were encountered:

adamjstewart commented Apr 6, 2020

alalazo commented Apr 7, 2020

How did you install the Intel compiler? I tried to reproduce this issue with an older version of the compiler that has been configured manually and registered as external but cmake installed correctly:

keltonhalbert commented Apr 7, 2020

@alalazo I have not personally installed the intel compiler, it’s the system default of the Frontera cluster at the University of Texas. I’m not quite sure how to isolate what part of this is actually the problem, but I did notice from the build log pasted above that there is an empty argument ‘—‘. Is it perhaps related to this?

I’m not super well versed in the Spack ecosystem, so I’m not sure how to debug or track down these sorts of issues, but if I can get some direction I’m happy to test and report back.

keltonhalbert commented Apr 7, 2020

I should note, it could very well be related to already installed packages. I was installing H5Z-ZFP when it failed on CMake, and subsequent attempts produced the same result.

alalazo commented Apr 9, 2020

I have not personally installed the intel compiler, it’s the system default of the Frontera cluster at the University of Texas.

Is the compiler available by loading a module after login? If so loading the module before running spack install changes the situation?

keltonhalbert commented Apr 9, 2020

keltonhalbert commented Apr 9, 2020 •

So, quick update on the issue.

So, the issue appears to lie in the master branch. Out of curiosity, from the user perspective is it expected that people should be using the release branches? If so, I might encourage updating the installation documentation, as it took digging into some other corners of the docs to figure out that was an option.

If you would like, I can close this issue now or leave it open until its addressed in Master.

svenevs commented Jun 14, 2020

Was playing around with this, all using a spack-compiled gcc@8.4.0 backend

If you’re reading this and you just need it to work ™️ you can cheat around this assuming you have cmake available either via another spack install, or system install by using cmake to build rather than bootstrapping. Here’s the ugly hack I did ( spack edit cmake ):

All other phases can remain the same. Hopefully that helps anybody who is stuck needing to get past this, but actually needs to compile it rather than mark it as external.

cmake @3.10.0: Cannot find a C++ compiler supporting C++11 on this system

Описание

cmake @3.10.0 fails to configure on Mountain Lion and earlier:

I thought we weren’t going to update cmake to a version that requires C++11 because that destroys MacPorts on earlier systems.

Вложения (5)

История изменений (69)

comment:1 Changed 5 лет ago by «>kencu (Ken)

I believe if we whitelist clang-3.7 to build cmake on these systems, we should be OK.

Clang-3.7 is the last clang that builds without cmake (at least as configured on MacPorts) and is able to handle c++11, so it should have no trouble building cmake.

For PPC, whitelist gcc6.

comment:2 Changed 5 лет ago by «>michaelld (Michael Dickens)

I didn’t realize that the 3.10.0 release required C++11. Should have tested on my 10.8 box. hopefully Ken’s suggestion works!

comment:3 Changed 5 лет ago by «>kencu (Ken)

Perhaps it needs a flag to function. Will explore.

comment:4 Changed 5 лет ago by «>kencu (Ken)

Nope. Not a flag. Some kind of weird error in bootstrap:

Changed 5 лет ago by «>kencu (Ken)

bootstrap fail with clang-3.7 / libstdc++ on 10.7

comment:5 Changed 5 лет ago by «>kencu (Ken)

looks like that might be it:

that’s a bit ugly. OK for 10.7+ (just force libc++) but for 10.6, not so simple. Perhaps a simple dependency on port:libcxx might do it, though.

comment:6 Changed 5 лет ago by «>kencu (Ken)

Perhaps something like this:

There are various compiler and stdlib forces in the cmake Portfile that might need to be cleaned up to make sure this works out, including a part where the stdlib is forced back to libstdc++ later on in the portfile (which I’ve had to delete out of each cmake portfile to build it, btw).

comment:7 Changed 5 лет ago by «>kencu (Ken)

Hah. Again, no. Triggers an error during linking on 10.7.

comment:8 Changed 5 лет ago by ballapete (Peter «Pete» Dyballa)

comment:9 Changed 5 лет ago by «>kencu (Ken)

so I think this clang-3.7/libc++ forcing might be the way forward for bootstrapping most older systems, but we have that issue with 10.7 that apparently is a unique thing. I’ll see if that is something easy to fix.

Most likely, all the compiler and stdlib forcing in the cmake Portfile will need to be redone, though.

comment:10 следующий: 11 Changed 5 лет ago by «>kencu (Ken)

Been playing with variations of this for the morning. It’s not an easy fix. The system libs are all installed with a different stdlib than cmake when you force libc++ on 10.7, so that all has to be rethought due to link errors. Frustratingly, the cmake internal libs don’t build smoothly on some systems due to all the usual hassles like incorrect typedefs etc. No doubt fixable, but more time. And then the next version of cmake will come out, and we start over again.

I thought perhaps gcc6 might build it (it does on PPC), but sadly even that failed on MacOS Intel.

It’s looking more tempting again to spin off the last version as a cmake-legacy port, and use that to step people through to building clang-4.0 or clang-5.0, and then use that to build the current cmake. However, automating that is not simple. People would probably have to follow a page of instructions.

comment:11 в ответ на: 10 ; следующие: 12 13 Changed 5 лет ago by «>ryandesign (Ryan Schmidt)

Been playing with variations of this for the morning. It’s not an easy fix. The system libs are all installed with a different stdlib than cmake when you force libc++ on 10.7, so that all has to be rethought due to link errors. Frustratingly, the cmake internal libs don’t build smoothly on some systems due to all the usual hassles like incorrect typedefs etc. No doubt fixable, but more time. And then the next version of cmake will come out, and we start over again.

I thought perhaps gcc6 might build it (it does on PPC), but sadly even that failed on MacOS Intel.

It’s looking more tempting again to spin off the last version as a cmake-legacy port, and use that to step people through to building clang-4.0 or clang-5.0, and then use that to build the current cmake. However, automating that is not simple. People would probably have to follow a page of instructions.

Perhaps you’re now understanding why we previously reached the conclusion that C++11 on libstdc++ systems isn’t workable?

Maybe I can ask a different question: Why do we need cmake 3.10.0? Can we downgrade to 3.9.6 and keep it there indefinitely? Since 3.10.0 just came out, it seems unlikely that other projects will mandate that version of cmake for another couple years at least. Or, offer 3.10.0 or later to libc++ systems and 3.9.6 to libstdc++ systems. (This has the problem, though, that we also really need to add support to MacPorts base and mprsyncup for separate libc++ portindexes on older systems.)

There is no «buildbot stdlib thing» to fix. Virtual machines destined to become buildbot workers for libc++ on 10.6, 10.7 and 10.8 have been provisioned for a year already. For them to become operational, we need to:

comment:12 в ответ на: 11 Changed 5 лет ago by «>kencu (Ken)

Perhaps you’re now understanding why we previously reached the conclusion that C++11 on libstdc++ systems isn’t workable?

I was not surprised to see Michael press on with cmake newer releases. Other package management systems proceed apace with cmake releases. Without dealing with the issue, we’d be stuck on 3.9 forever, so we might as well sort it out.

There is no «buildbot stdlib thing» to fix.

The steps you outlined are what I was referring to.

Somehow have to force that cmake39 version on systems without cmake installed if they try to install something that needs cmake. That would be easy enough to do in the cmake PortGroup, with a system test:

comment:13 в ответ на: 11 Changed 5 лет ago by «>ryandesign (Ryan Schmidt)

Wouldn’t it be simpler to modify the one cmake portfile to:

Can we [. ] offer 3.10.0 or later to libc++ systems and 3.9.6 to libstdc++ systems.

Requires no modification to portgroup or other ports.

comment:14 Changed 5 лет ago by «>kencu (Ken)

10.7 configured to libc++ can’t build the current cmake, for example, and has to be forced back to libstdc++ for the build to work. Weird stuff.

systems configured with stdlib=libstdc++ set up with the cxx11 1.1 PG can build the most recent cmake if they have a new clang like clang-5.0 installed, so really shouldn’t be held back to 3.9.6. for any particular reason.

Also, if we did spin off cmake39 for older systems, Michael might be able to clean out a lot of legacy crud in that cmake Portfile and start lean and fresh going forward.

comment:15 Changed 5 лет ago by «>MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

comment:16 Changed 5 лет ago by «>MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

I was able to get cmake to build on a 10.7 VM using libstdc++ with the following steps:

comment:17 Changed 5 лет ago by «>kencu (Ken)

I think it would be best if I left the rest of this decision-making process to you and Ryan and Michael, as you all have so much more experience with it and it’s so integral to the function of MacPorts.

comment:18 Changed 5 лет ago by iEFdev

comment:19 Changed 5 лет ago by «>michaelld (Michael Dickens)

comment:20 Changed 5 лет ago by «>michaelld (Michael Dickens)

And, maybe #55415 isn’t quite a duplicate, but the efforts are similar & the end result is likely to address both tickets.

comment:21 Changed 5 лет ago by «>mojca (Mojca Miklavec)

comment:22 Changed 5 лет ago by «>fvaccari

comment:23 Changed 5 лет ago by «>kencu (Ken)

It looks highly likely that part of this fix will involve a cmake39 port. Is everyone OK if I push that through? It will help get peoplr ruuning, and fulfill the cmake test in the cmake PG file.

comment:24 следующий: 25 Changed 5 лет ago by «>ryandesign (Ryan Schmidt)

I don’t understand how that can work. If cmake and cmake39 conflict and both install /opt/local/bin/cmake, and if you make one of cmake’s dependencies depend on cmake39, then cmake will eventually fail to activate because cmake39 is active.

comment:25 в ответ на: 24 Changed 5 лет ago by «>MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

I don’t understand how that can work. If cmake and cmake39 conflict and both install /opt/local/bin/cmake, and if you make one of cmake’s dependencies depend on cmake39, then cmake will eventually fail to activate because cmake39 is active.

Wouldn’t the following code in the ​ cmake PG break the circular dependency?

comment:26 Changed 5 лет ago by «>ryandesign (Ryan Schmidt)

Not circular dependency; activation conflict.

If you’re proposing that cmake should depend on clang-X.Y (where X.Y is 3.8 or greater), and you’re proposing that clang-X.Y should depend on cmake39 as a bootstrapping measure, then here’s what will happen:

If we want to offer cmake 3.10 and later to libstdc++ systems—and I agree it would be best to do so if we can without too much grief for both us and the user—then having a cmake bootstrap port install cmake 3.9.6 to a different private location to avoid activation conflicts would be less error-prone.

But I’m still not clear whether we need a cmake 3.9.6 bootstrap port at all. Can’t cmake 3.10+ just build using clang-3.7, which does not depend on cmake, as Ken suggested in comment:1? cmake is only a program, not a library, so nothing will be linking with it; and as far as I can tell, of cmake’s dependencies, only the ncurses port contains a library that uses C++, and cmake only links with libncurses, not libncurses++; so it should be fine to force cmake to use libc++ on older systems, just like I do for mongodb for the same reasons ([06570abb7bb41aaf8058fbad159163374a8ed61c/macports-ports], [7339137c4e501aa383516859235fa3fb17906332/macports-ports]).

I’m not sure if we can use libc++ on Tiger and Leopard. I see that the current cmake 3.10.0 port built just fine on 10.5 PPC with gcc6. We could do the same on 10.5 Intel and 10.4. The cxx11-1.1 portgroup currently uses gcc6 only on PowerPC. Maybe it should be changed to use gcc6 on 10.5 and earlier regardless of arch.

How to detect C++11 support of a compiler with CMake

Is there a way to let CMake detect automatically if a compiler supports C++11 or not?

As it would be nice to inform the users during the CMake run that the code will not compile as the compiler does not support C++11. At the moment I set the C++11 flags. However, if a compiler does not support it the user gets compile errors instead of an error during the CMake run.

Is there something available or do I need to develop this on my own?

Below is some code I use so far, however it works only with GNU’c GCC compilers. It would be nice if there would be a more general solution.

6 Answers 6

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

If you have CMake version 3.1.0 or later you can detect what C++ features your C++ compiler supports

1. Specifying the C++ standard explicitly

You could specify the C++ standard explicitly, by setting the CMake properties CXX_STANDARD and CXX_STANDARD_REQUIRED for your CMake target.

2. Specifying the required C++ features and let CMake induce the C++ standard

You could use the CMake command target_compile_features to specify the C++ features that are made use of in your CMake target. From this list CMake will induce the C++ standard to be used. The CMake global property CMAKE_CXX_KNOWN_FEATURES lists the C++ features you can choose from.