我的操作系统是centos,它在路径/usr/bin/gcc中具有默认的gcc。 但是它很旧,我需要新版本的gcc。 因此,我在新路径/usr/local/bin/gcc中安装了新版本。
但是当我运行cmake时,它仍然使用旧版本的gcc path(/usr/bin/gcc)。 我如何指定gcc到新路径(/usr/local/bin/gcc)。
我试图用/usr/local/bin/gcc覆盖/usr/bin/gcc,但是它不起作用。
-
我认为将替代gcc版本安装到opt而不是usrlocal是一个好习惯。 优选optgcc-x.y.z。 这样,如果您需要更高的版本,则可以轻松卸载以前的版本。
在调用cmake之前,请勿覆盖CMAKE_C_COMPILER,而是导出CC(和CXX):
1 2 3 4
| export CC=/usr/local/bin/gcc
export CXX=/usr/local/bin/g++
cmake /path/to/your/project
make |
首次配置项目时,只需要执行一次导出,然后将从CMake缓存中读取这些值。
更新:更长的解释,为什么在杰克发表评论后不改写CMAKE_C(XX)_COMPILER
我建议不要重写CMAKE_C(XX)_COMPILER值,主要有两个原因:因为它不能与CMake的缓存配合使用,并且因为它破坏了编译器检查和工具检测。
使用set命令时,有三个选项:
-
没有缓存,创建普通变量
-
带有缓存,以创建一个缓存的变量
-
强制缓存,在配置时始终强制缓存值
让我们看看对set的三个可能的调用会发生什么:
没有缓存
1 2
| set(CMAKE_C_COMPILER /usr/bin/clang )
set(CMAKE_CXX_COMPILER /usr/bin/clang++ ) |
这样做时,您将创建一个"普通"变量CMAKE_C(XX)_COMPILER,该变量隐藏相同名称的缓存变量。这意味着您的编译器现在已在您的构建脚本中进行了硬编码,并且您无法为其赋予自定义值。如果您具有使用不同编译器的多个构建环境,这将是一个问题。每次您要使用其他编译器时,您都可以更新脚本,但这首先消除了使用CMake的价值。
好的,那么,让我们更新缓存...
带缓存
1 2
| set(CMAKE_C_COMPILER /usr/bin/clang CACHE PATH"")
set(CMAKE_CXX_COMPILER /usr/bin/clang++ CACHE PATH"") |
此版本将"不起作用"。 CMAKE_C(XX)_COMPILER变量已经在缓存中,因此除非您强制执行,否则它不会更新。
啊...让我们用力,然后...
强制缓存
1 2
| set(CMAKE_C_COMPILER /usr/bin/clang CACHE PATH"" FORCE)
set(CMAKE_CXX_COMPILER /usr/bin/clang++ CACHE PATH"" FORCE) |
这几乎与"普通"变量版本相同,唯一的区别是您的值将在缓存中设置,因此用户可以看到它。但是任何更改都将被set命令覆盖。
破坏编译器检查和工具
在配置过程的早期,CMake会对编译器进行检查:是否起作用?它能够产生可执行文件吗?等等。它还使用编译器来检测相关工具,例如ar和ranlib。当您在脚本中覆盖编译器值时,它"太迟了",所有检查和检测都已完成。
例如,在使用gcc作为默认编译器的计算机上,当对/usr/bin/clang使用set命令时,ar被设置为/usr/bin/gcc-ar-7。在运行CMake之前使用导出时,将其设置为/usr/lib/llvm-3.8/bin/llvm-ar。
-
如果在$ PATH中设置了正确的编译器,则等效于惰性的:> export CC = which gcc> export CXX = which g++
-
如果在$ PATH中设置了正确的编译器,则等效于惰性的:export CC=`which gcc` export CXX=`which g++`
-
如果CC / CXX与路径不同,我得到Incorrect gcc version compiler.version=5.3 is not the one detected by CMake: GNU=4.8
-
如果在Windows上安装Im,该怎么办?
-
@ mr5未测试,但认为您应该能够在命令提示符下执行set CC=...。
-
为什么建议您不要使用CMAKE_C_COMPILER和CMAKE_CXX_COMPILER?
-
@Jake在评论中回答可能太久了,所以我更新了答案:)
-
实际上,如果您使用命令行$ cmake -GNinja -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ pathtosource进行设置,则设置CMAKE_C_COMPILER的效果很好。
-
此解决方案并不总是有效。您需要清除CMake缓存以重新读取CC和CXX环境变量。它还假定使用Bash或类似的Shell。这是没有这些限制的最新答案:stackoverflow.com/a/50494125/7328782
这个问题很老,但仍然出现在Google搜索上。可以接受的问题不再对我有用,并且似乎已经老了。有关cmake的最新信息写在cmake FAQ中。
有多种方法可以更改编译器的路径。一种方法是
Set the appropriate CMAKE_FOO_COMPILER variable(s) to a valid compiler
name or full path on the command-line using cmake -D. For example:
1
| cmake -G"Your Generator" -D CMAKE_C_COMPILER=gcc-4.2 -D CMAKE_CXX_COMPILER=g++-4.2 path/to/your/source |
代替gcc-4.2,您可以这样写path/to/your/compiler
1
| cmake -D CMAKE_C_COMPILER=/path/to/gcc/bin/gcc -D CMAKE_CXX_COMPILER=/path/to/gcc/bin/g++ . |
-
我这样做的时候,是在旧的编译器(GCC 5.3)上构建旧项目,而环境中却有更新的编译器(GCC 7.3)。它运行良好并且可以在我的机器上工作,但是一旦我将可执行文件移到另一台机器上,我意识到程序是从源7.3而不是请求的5.3链接到libstdc ++。so的。
将CMAKE_C_COMPILER设置为新路径。
参见此处:http://www.cmake.org/Wiki/CMake_Useful_Variables
导出应具体说明要使用的GCC / G ++版本,因为如果用户具有多个编译器版本,则将无法成功编译。
1 2 3 4
| export CC=path_of_gcc/gcc-version
export CXX=path_of_g++/g++-version
cmake path_of_project_contain_CMakeList.txt
make |
如果项目使用C ++ 11,则可以通过使用CMakeList.txt中的-std=C++-11标志来处理
另一种解决方案是通过cmake-gui从干净的构建目录开始配置项目。在开始时可用的选项中,有可能选择编译器的确切路径
这不仅适用于cmake,而且适用于./configure和make:
1
| ./configure CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ |
结果是:
1 2
| checking for gcc... /usr/local/bin/gcc
checking whether the C compiler works... yes |