CODEWITHSUNDEEP
c++cmakec++17
Lamda
Lamda

Reputation: 944

Target requires the language dialect "CXX17" (with compiler extensions), but CMake does not know the compile flags to use to enable it

So I've been trying to include the <filesystem> into my project, which seem to be a bigger problem than I thought. <filesystem> should be part of c++17, I need to add that definition into my CMakeList.

My root CmakeLists look like this: 

MESSAGE(“In src CMAKELIST”)

#
# Build everything in include/ directory
add_subdirectory(include)
#

#set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
#set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

## Main executable target
add_executable(cmakeDemo main.cpp)

# These libraries get built in include/*/, CMake will auto-set required
# compiler flags and include paths from their definitions
target_link_libraries(cmakeDemo record ${portaudio})
target_link_libraries(cmakeDemo database)
target_link_libraries(cmakeDemo match)
target_link_libraries(cmakeDemo spectogram)

In which I added the c++17 definition, but when I compile my system, I get this error:

 make 
“InsrcCMAKELIST”
“InincludeCMAKELIST”
“IndatabaseCMAKELIST”
“InmatchCMAKELIST”
“InrecordCMAKELIST”
“InspectogramCMAKELIST”
/home/lamda/soundcloud/src/include/spectogram/base/base.h
“outspectogramCMAKELIST”
-- Configuring done
CMake Error in src/CMakeLists.txt:
  Target "cmakeDemo" requires the language dialect "CXX17" (with compiler
  extensions), but CMake does not know the compile flags to use to enable it.


-- Generating done
-- Build files have been written to: /home/lamda/soundcloud/build
make: *** [cmake_check_build_system] Error 1

But somehow isn't it willing to use c++17, so I can use the filesystem library? why?

Upvotes: 16

Views: 39721

Answers (4)

Dylan B
Dylan B

Reputation: 1012

don't compile gcc, in centOS you can install devtoolset-8-gcc

yum -y install devtoolset-8-gcc devtoolset-8-gcc-c++ devtoolset-8-binutils
sudo ln -s /opt/rh/devtoolset-8/root/usr/bin/gcc /usr/bin/cc
sudo ln -s /opt/rh/devtoolset-8/root/usr/bin/g++ /usr/bin/c++

Upvotes: 0

chtimi59
chtimi59

Reputation: 539

Update about gcc

Building our own GCC from the sources is actually a bad idea...

In my case I get some errors by trying to link with an external library (even made with the same c++ standart /GCC version)

The best practice seems to use devtoolset yum package instead https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/

It seems that this package has been made by including some Redhat patches an configure switch for you. So as far we don't known the magic recipe to make it work properly, it make sens to use something more official.

Conlusion: use devtoolset yum package instead or trying to compile GCC from sources

Upvotes: 4

chtimi59
chtimi59

Reputation: 539

I was facing to the same issue, but if the answer was a good start, it wasn't enough (at least for me).

So here how I fix it (on a centos7 distro)

1. CMAKE > 3.8

On centos 'sudo yum info cmake' says '2.8.12'

so I have had to follow those instructions: https://cmake.org/download/ to actually ends with a '3.14.5' version

2. GCC/C++17 > 5.1.0

As mentioned by @Lamda, the tools chain need to be updated,

otherwise you will still stay stuck on the exact same error message.

Here is how CMAKE checks supported dialect: https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU-CXX.cmake#L45

if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 8.0)
  set(CMAKE_CXX17_STANDARD_COMPILE_OPTION "-std=c++17")
  set(CMAKE_CXX17_EXTENSION_COMPILE_OPTION "-std=gnu++17")
elseif (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1)
  set(CMAKE_CXX17_STANDARD_COMPILE_OPTION "-std=c++1z")
  set(CMAKE_CXX17_EXTENSION_COMPILE_OPTION "-std=gnu++1z")
endif()

and again, no luck with the centos, 'sudo yum info gcc' says '4.8.5'

I've decide to compile GCC from the source code directly, with something like this:

wget ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-7.2.0/gcc-7.2.0.tar.gz
tar -xvzf gcc-7.2.0.tar.gz
cd gcc-7.2.0
./contrib/download_prerequisites
./configure \
    --enable-bootstrap \
    --enable-languages=c,c++,fortran,lto \
    --with-bugurl=http://bugzilla.redhat.com/bugzilla \
    --enable-shared \
    --enable-threads=posix \
    --enable-checking=release \
    --disable-multilib \
    --with-system-zlib \
    --enable-__cxa_atexit \
    --disable-libunwind-exceptions \
    --enable-gnu-unique-object \
    --enable-linker-build-id \
    --with-gcc-major-version-only \
    --enable-plugin \
    --with-linker-hash-style=gnu \
    --enable-initfini-array \
    --enable-libmpx \
    --enable-gnu-indirect-function \
    --with-tune=generic \
    --build=x86_64-redhat-linux
make -j4
sudo make install
sudo sh -c 'echo /usr/local/lib > /etc/ld.so.conf.d/1-gcc.conf'
sudo sh -c 'echo /usr/local/lib64 >> /etc/ld.so.conf.d/1-gcc.conf'
sudo ldconfig -v

Hence I ends with a GCC 7.2.0.

if succeed, the following test should returns 201402L

g++ -dM -E -x c++ /dev/null | grep -F __cplusplus

3. Still the same "dialect "CXX17" error ?

In my case, something else was needed to make it works:

sudo ln -s /usr/local/bin/gcc /usr/local/bin/cc

Why? You may ask...

GCC.7.2.0 actually don't seems to come with 'cc' (which should be trivial symblink to 'gcc')

On the other hand, CMAKE determine 'g++' path, by using 'cc' path (as a hint)

In my case I still have a /bin/cc #4.8.5 and /bin/g++ #4.8.5

so even if a /usr/local/bin/g++ #7.2.0 now exists (which should by used in prior)

CMAKE will unfortunately used /bin/g++ #4.8.5 instead

But, obviously the best practices would be to remove the whole old GCC tool Chain.

Upvotes: 12

Lamda
Lamda

Reputation: 944

As mentioned is c++17 only supported by cmake version > 3.8, so I had to update it.

But my problem was my gcc and g++ didn't support it, so I had to update those, which I then did.

I followed this guide.

Upvotes: 20

Related Questions