做C/C开发时间长了几乎都会碰到那个熟悉又头疼的场景接手一个三年前的老项目第一遍编译就报出一大堆警告和错误仔细一看全是系统里gcc版本太新闹的。老代码里那些当年被编译器欣然接受的写法在新标准下已经被判了死刑。反过来也一样想在新项目里试试C20的特性系统自带的gcc却还停在原地。这类问题的解法说穿了就一句话在一台机器上安装多个版本的gcc按项目需要随时切换。今天这篇就围绕gcc多版本切换这件事把环境准备、安装步骤、切换原理、踩坑排查完整过一遍。文章主要面向Linux开发环境会分别讲Ubuntu/Debian系和RHEL/CentOS系的做法也会把gcc升级后还是旧版本、VSCode里提示gcc不是内部或外部命令、离线安装gcc失败这些高频问题一并梳理掉。无论你是刚入门的C/C新手还是被老工程折腾过的老手这套方案都能让你少走不少弯路。1. 环境准备与方案选型思路1.1 为什么要让gcc多版本共存很多人一开始不理解系统里装一个gcc不是挺好的吗多个版本共存不是给自己找麻烦但实际工程里版本错配带来的麻烦远比多装几个编译器大得多。先看C/C标准演进。GCC 8开始比较完整地支持C17GCC 11才算比较完整地支持C20GCC 12以后才对C23的部分特性有了初步实现。如果你想把一个老项目用C17标准重新编译系统还停留在GCC 7甚至GCC 4.8那很多特性根本用不了。反过来一些老库和老SDK为了兼容性明确要求只能用某个旧版本编译比如某些嵌入式厂商的SDK到现在还推荐GCC 4.8或者GCC 7.5用新版本编译就出各种奇奇怪怪的链接错误。再看ABI兼容性。GCC大版本升级之后libstdc的动态库符号可能发生变化用GCC 13编译出来的C程序拿到只有GCC 4.8那套运行库的老服务器上跑大概率会报GLIBCXX_3.4.x not found。这种运行时问题比编译错误更难排查。还有一个很实际的场景不同项目对编译器版本的要求不同。A项目要求GCC大于等于9B项目要求小于等于8如果机器上只有一个系统默认gcc每天工作的一部分时间就浪费在装环境、卸环境、重新编译上了。多版本共存本质上解决的是“一台机器同时应对多种编译需求”的问题。1.2 方案选型update-alternatives、符号链接还是容器要实现多版本gcc切换主流做法有三类先做一个对比再决定用哪种。第一类是Debian系特有的update-alternatives机制。它把/usr/bin/gcc变成指向/etc/alternatives/gcc的符号链接再由alternatives管理这个链接指向哪个真实版本。优点是有优先级、有交互式切换界面、有统一的命令管理适合系统级切换。缺点是仅Debian/Ubuntu系原生支持RHEL系虽然也有alternatives但在gcc版本管理上远不如scl方便。第二类是手动管理符号链接。直接ln -sf把/usr/bin/gcc指向具体某个版本。优点是非常通用任何Linux发行版都能用逻辑最简单出了问题自己心里有数。缺点是没有任何优先级概念换版本全靠手动执行命令或者脚本容易忘记顺手切换g。第三类是用环境变量隔离编译时通过CC/usr/bin/gcc-10 CXX/usr/bin/g-10指定编译器。这种方式最适合单个项目、单个shell不污染系统全局配置也不影响其他终端里的默认编译器。如果再激进一点可以直接上Docker容器每个容器里只装一个gcc版本彻底隔离适合老项目编译环境复现。下面用一个表格做对比方便根据自己的场景快速选型。方案适用场景优点缺点管理难度update-alternativesUbuntu/Debian系统级默认切换统一管理支持优先级仅Debian系原生切换影响全局低手动符号链接所有Linux发行版简单直接通用性强无优先级容易漏切g中CC/CXX环境变量单个项目编译不污染系统最安全只对当前shell/工程有效低Docker容器老项目环境复现完全隔离版本固定需要Docker环境镜像体积大中1.3 动手前先摸清系统底细不管选择哪条路线第一步永远是搞清楚当前系统的状态。打开终端逐条执行下面的命令cat /etc/os-release uname -m gcc --version which gcc ls -l /usr/bin/gcc* echo $PATH这些命令分别解决几个问题确认发行版和版本号判断是Debian系还是RHEL系确认系统架构是x86_64还是arm64这决定了后面软件包和源码编译的参数确认现在系统默认的gcc是哪个版本是从哪个路径调用的确认PATH环境变量里有哪些目录可能影响gcc的查找顺序。这里特别提醒一下which gcc看到的路径不一定能反映真实情况。比如Ubuntu上which gcc通常返回/usr/bin/gcc但ls -l /usr/bin/gcc会告诉你它其实是一个指向/etc/alternatives/gcc的符号链接。多看一眼软链的指向能避免后面出现“明明切换了版本gcc --version却还是老版本”的困惑。2. Ubuntu/Debian系安装多版本GCC的完整步骤2.1 用软件源快速安装指定版本Ubuntu/Debian系最省事的办法是直接用apt包管理器安装gcc的指定版本。Ubuntu的软件源里通常打包了多个版本的gcc先查一下仓库里有哪些版本可选apt-cache search ^gcc-[0-9]$ apt-cache search ^g-[0-9]$以Ubuntu 20.04为例默认源里大概率能看到gcc-7、gcc-8、gcc-9、gcc-10这些版本。需要哪个就装哪个一条命令的事sudo apt update sudo apt install -y gcc-9 g-9 gcc-10 g-10这里有个细节容易被忽略apt install gcc-10只会装gcc-10这个C编译器不会自动带g-10。如果后面要编译C代码得把对应的g版本也装上。最稳妥的做法是把gcc-N和g-N一起装保持C和C编译器版本一致。如果需要的版本不在官方源里比如在Ubuntu 18.04上想装gcc-13这时候需要添加社区维护的toolchain-r PPAsudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt update sudo apt install -y gcc-13 g-13这个PPA在开发者群体里使用量很大专门提供较新版本的gcc工具链基本覆盖了Ubuntu LTS版本上那些软件源里没有的新版本。添加PPA之后之前搜不到的gcc-11、gcc-12、gcc-13一般都出来了。安装完成之后可以用通配符确认多版本共存的状态ls -l /usr/bin/gcc* ls -l /usr/bin/g*正常情况下你会看到gcc、gcc-9、gcc-10、g、g-9、g-10这些文件同时存在其中gcc和g指向系统默认版本。2.2 源码编译安装特定版本GCC软件源方案虽然方便但覆盖不了所有情况。比如你需要一个带特定配置参数的gcc或者软件源仓库里压根没有目标版本这时候只能源码编译安装。以GCC 8.3.0为例先说依赖。编译GCC本身需要GMP、MPFR、MPC这三个数学库还需要flex、bison这些工具一次性装齐sudo apt install -y build-essential flex bison libgmp-dev libmpfr-dev libmpc-dev然后下载源码。GCC官方源码放在GNU的FTP镜像上用wget拉取wget https://ftp.gnu.org/gnu/gcc/gcc-8.3.0/gcc-8.3.0.tar.gz tar -xzf gcc-8.3.0.tar.gz重点来了编译GCC强烈建议用“源码目录外的构建目录”也就是out-of-source build。这样做的原因是避免编译产物污染源码目录也方便在同一个源码目录基础上用不同参数构建多次。操作流程mkdir gcc-8.3.0-build cd gcc-8.3.0-build ../gcc-8.3.0/configure --prefix/usr/local/gcc-8.3.0 --enable-languagesc,c --disable-multilib make -j$(nproc) sudo make installconfigure参数里的--prefix/usr/local/gcc-8.3.0是安装路径非常重要。我习惯把不同版本装到不同目录这样不会和系统自带的gcc抢位置后续切换和清理都方便。--enable-languagesc,c只编译C和C编译器如果你不需要Fortran、Go、Ada这些就别浪费时间编译它们。--disable-multilib在64位系统上可以显著减少编译工作量因为不需要生成32位的兼容库。编译时间取决于机器性能GCC本身是个庞然大物全量编译少则半小时多则两三个小时。make -j$(nproc)用全部核心并行编译但如果机器内存不大建议手动限制并行度比如make -j4否则并行编译时内存会被瞬间吃满整机卡死得不偿失。2.3 安装后配置动态库路径源码安装完的gcc可执行文件在/usr/local/gcc-8.3.0/bin/下。直接用全路径调用一般能正常工作/usr/local/gcc-8.3.0/bin/gcc --version /usr/local/gcc-8.3.0/bin/g --version但如果你打算把源码安装的gcc作为默认编译器使用光有可执行文件还不够。新版gcc自带一套libstdc和libgcc_s动态库存在于/usr/local/gcc-8.3.0/lib64/目录下。如果系统的动态链接器找不到这个目录你用新版本gcc编译出来的程序运行时会报libstdc.so.6: cannot open shared object file或者CXXABI_1.3.x not found之类的错误。解决办法是把这个目录加入动态链接器的搜索路径echo /usr/local/gcc-8.3.0/lib64 | sudo tee /etc/ld.so.conf.d/gcc-8.3.0.conf sudo ldconfig执行完ldconfig之后用ldd验证一下编译出来的程序能不能正确找到动态库ldd /usr/local/gcc-8.3.0/bin/gcc看到libstdc.so.6 /usr/local/gcc-8.3.0/lib64/libstdc.so.6这样的输出就说明库路径已经生效了。这一环节很容易被忽略多数情况下编译时没有问题问题全部暴露在运行阶段排查起来反而更费劲。3. 多版本切换的两种实现方式与验证3.1 用update-alternatives实现一键切换如果前面的安装工作已经完成现在到了最核心的部分让多个版本之间可以快速切换。先看Ubuntu下update-alternatives的工作原理。执行ls -l /usr/bin/gcc你会看到类似下面的输出lrwxrwxrwx 1 root root 21 ... /usr/bin/gcc - /etc/alternatives/gcc也就是说/usr/bin/gcc并不是真实的可执行文件而是一个指向/etc/alternatives/gcc的符号链接。/etc/alternatives/gcc再进一步指向真正要使用的gcc二进制文件比如/usr/bin/gcc-10。这一层间接管理的意义在于切换版本时只需要修改/etc/alternatives/gcc这个软链的指向所有调用/usr/bin/gcc的程序都会自动跟随变化。把已有的gcc版本登记到alternatives里使用如下命令sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 90 \ --slave /usr/bin/g g /usr/bin/g-9 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 \ --slave /usr/bin/g g /usr/bin/g-10参数拆解第一个参数/usr/bin/gcc是希望被管理的符号链接路径第二个参数gcc是这个链接组的名称第三个参数/usr/bin/gcc-9是真实可执行文件的路径第四个参数90是优先级数字越大默认越优先。最后的--slave选项把g和gcc绑定到同一个组里切换gcc时g跟着一起变避免“gcc是10、g还是9”的错位。切换版本时交互式命令最直观sudo update-alternatives --config gcc终端会显示一个带编号的列表标出当前选中的版本输入数字回车即可完成切换。如果在脚本里需要非交互式切换用--setsudo update-alternatives --set gcc /usr/bin/gcc-10查看当前alternatives状态用update-alternatives --display gcc。要移除某个登记过的版本用sudo update-alternatives --remove gcc /usr/bin/gcc-9这个操作只是把版本从alternatives列表里移除不会真的卸载gcc-9软件包。3.2 通用的手动符号链接切换法如果你用的发行版不带update-alternatives或者你更喜欢一切尽在掌握的感觉手动符号链接方案会更适合。核心逻辑就一条把/usr/bin/gcc这个软链直接指向目标版本。sudo ln -sf /usr/bin/gcc-10 /usr/bin/gcc sudo ln -sf /usr/bin/g-10 /usr/bin/g切回gcc-9时再执行一次sudo ln -sf /usr/bin/gcc-9 /usr/bin/gcc sudo ln -sf /usr/bin/g-9 /usr/bin/g手动方式的问题在于容易忘事。今天换了gcc明天g还是旧的或者某个版本在切换时被软链指向了一个不存在的路径。为了避免这种低级错误我一般会写一个带参数的小脚本把版本切换封装起来。#!/bin/bash # switch-gcc.sh — 手动切换gcc/g版本 # 用法: ./switch-gcc.sh 9 或 ./switch-gcc.sh 10 set -e VER$1 if [ -z $VER ]; then echo Usage: $0 {9|10|...} exit 1 fi sudo ln -sf /usr/bin/gcc-$VER /usr/bin/gcc sudo ln -sf /usr/bin/g-$VER /usr/bin/g echo Switched to: gcc --version | head -n 1 g --version | head -n 1强调一点手动符号链接和update-alternatives会同时操作/usr/bin/gcc这个路径两者混用可能产生冲突。如果你之前用update-alternatives管理过临时改成手动切换脚本建议先把alternatives里对应的注册项移除再切到手动方式。3.3 切换后必须做的验证动作切换完版本不要急着开始编译项目花半分钟做几项验证能省下后面很多排查时间。首先确认当前生效的编译器和真实路径gcc --version g --version which gcc readlink -f /usr/bin/gcc其次用一个最简单的程序验证编译和运行链路顺便通过__VERSION__宏确认编译器版本确实是你想要的cat ver.cpp EOF #include iostream int main() { std::cout GCC version: __VERSION__ std::endl; return 0; } EOF g ver.cpp -o ver ./ver如果输出的__VERSION__和gcc --version显示的版本不一致那说明编译时调用的g和运行环境的gcc路径存在错位优先检查软链指向。还要注意构建系统的缓存问题。如果你的项目之前用CMake配置过CMake会把编译器路径缓存到CMakeCache.txt里。切换gcc版本后建议删除CMakeCache.txt重新执行cmake否则CMake可能继续用旧编译器。Makefile项目同样建议执行make clean后再重新编译。很多人在切换版本后抱怨“make报错没变化”八成就是缓存没清理。4. RHEL/CentOS系与离线场景的gcc多版本管理4.1 用yum/dnf安装并切换多版本RHEL系的情况和Ubuntu不太一样。CentOS 7自带的gcc版本是4.8相当古老想用新版本最正统的路线是Software Collections简称SCL。SCL的设计思想是把多个版本的工具链安装到/opt/rh/下的独立目录里通过环境变量切换不覆盖系统默认版本。CentOS 7上安装新版本gcc的步骤sudo yum install -y centos-release-scl sudo yum install -y devtoolset-9-gcc devtoolset-9-g启用devtoolset-9scl enable devtoolset-9 bash gcc --versionscl enable devtoolset-9 bash的机制是启动一个子shell在这个shell里PATH、LD_LIBRARY_PATH等环境变量被修改指向/opt/rh/devtoolset-9/root/下的工具链。这个操作只在当前shell生效退出终端后自动恢复系统默认版本。CentOS 8/RHEL 8及以后的系统命令类似不过安装包名字换成了gcc-toolsetsudo dnf install -y gcc-toolset-10 gcc-toolset-10-gcc-c scl enable gcc-toolset-10 bash如果希望每次登录终端都自动启用新版gcc可以把source命令写进~/.bashrc。个人不太推荐这种做法因为会让所有终端默认使用新版gcc失去SCL按需启用的意义。我更习惯在需要新版本的那个终端里手动执行scl enable或者干脆用绝对路径调用新版本gcc。4.2 用devtoolset与系统gcc共存时的注意事项SCL方案虽然方便但有几个坑需要提前知道。第一个坑是脚本和定时任务。crontab或者systemd任务默认不会source SCL的enable脚本即使你之前在交互终端里scl enable过定时任务执行时依然用的是系统默认gcc。解决办法是在脚本内部显式source环境文件#!/bin/bash source /opt/rh/devtoolset-9/enable gcc --version第二个坑是动态库路径。用devtoolset编译的程序运行时依赖的是/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/下的libstdc等动态库。如果把编译产物复制到没有devtoolset的机器上运行时会报找不到库。如果目标机器也装了devtoolset需要设置LD_LIBRARY_PATH才能正常跑起来。第三个坑是编译时使用的头文件顺序。SCL的include目录优先如果项目里混用了系统库和新版gcc可能出现头文件版本和库版本不匹配的情况。遇到这类问题重点检查编译命令里有没有把/usr/include这种系统路径硬编码在错误的位置。4.3 离线环境安装gcc的两个务实路线离线安装gcc是很多人实际遇到的场景尤其内网开发机没法直接访问公网软件源。这里给出两条经过验证的路线。路线A用rpm包离线安装。在一台能联网的同版本、同架构机器上先把需要的rpm包和所有依赖下载到一个目录sudo yum install -y yum-utils mkdir -p /tmp/gcc-rpms yum install --downloadonly --downloaddir/tmp/gcc-rpms gcc gcc-c然后把/tmp/gcc-rpms整个目录拷贝到离线机器执行cd /tmp/gcc-rpms yum localinstall -y *.rpm注意yum localinstall会自动解析依赖顺序这是比rpm -Uvh *.rpm更稳妥的方式。rpm命令本身不处理依赖如果rpm包之间有严格的顺序要求直接rpm -Uvh *.rpm很可能会报依赖不满足。路线B源码编译但用旧版gcc做引导。如果你的离线机器上已经存在一个旧版gcc那么可以按照2.2节的方式在有网机器上下载所需版本的GCC源码包拷贝进离线机器用旧版gcc作为引导编译器去编译新版本。这个方案可行因为GCC本身支持自举编译旧版本能编译出新版本的编译器。还有一种更省事的变通方案如果离线机器允许使用Docker可以在联网机器上拉取一个包含目标gcc版本的镜像然后docker save导出tar包拷贝到离线机器后用docker load导入直接运行。这个方案能保留完整的编译环境也避开了rpm依赖问题。5. 高频问题排查与避坑实录5.1 “apt install gcc -y”失败与依赖错误修复Ubuntu下apt install gcc -y安装失败是搜索热度很高的一个问题多数情况并不是gcc包本身的问题而是软件源状态异常。常见的错误是提示E: Unable to locate package gcc。这个报错一般有两个原因要么系统从未执行过sudo apt update软件源索引是空的要么当前系统版本对应的源里没有universe组件。解决方法sudo apt update sudo apt install -y software-properties-common如果提示依赖关系错误比如某个依赖包版本不满足先尝试修复sudo apt --fix-broken install这个过程会尝试补齐缺失的依赖包。如果--fix-broken解决不了检查一下是不是混用了多个版本的apt源。有些教程让用户同时添加多个PPA不同PPA里的包版本互相冲突就会导致依赖地狱。CentOS/RHEL下yum install -y gcc失败常见原因是源配置错误或者缓存异常。执行yum clean all yum makecache重建缓存后再试。如果依然失败重点排查/etc/yum.repos.d/下的repo文件特别是内网镜像源配置是否正确。5.2 升级了gcc但怎么还是旧版本“明明执行了apt install gcc-10运行gcc --version还是老版本”这个问题非常有代表性原因其实有好几层逐个排查。第一层你安装的是gcc-10这个独立软件包但系统默认的/usr/bin/gcc软链依然指向旧的gcc-9。apt的默认行为只是把gcc-10这个包装上不会自动把系统的默认gcc切换过去。需要你手动执行update-alternatives或者符号链接切换这一步很多人忘了。第二层PATH环境变量的顺序问题。如果你的PATH里存在/usr/local/bin这样的目录并且里面也有一个gcc那么which gcc可能返回的是/usr/local/bin/gcc而不是/usr/bin/gcc。用which -a gcc列出所有候选路径再用readlink -f查看真实指向就能判断当前实际调用的是哪个。第三层shell的命令路径缓存。bash会缓存已经查找过的命令路径如果PATH变了或者软链指向变了当前终端可能还在用旧缓存。执行hash -r清除缓存或者直接开一个新终端。还有一个比较隐蔽的问题如果你的项目用make或cmake构建它们可能已经缓存了编译器路径。切换gcc版本后光看gcc --version是新的但make编译时依然调旧编译器。这种情况需要清理构建系统的缓存并重新配置。5.3 gcc与g版本错位很多开发者切换版本时只关注gcc忽视了g结果C代码编译一切正常C代码编译报出和版本相关的诡异错误。出现版本错位的根本原因是gcc和g分别被注册成了独立的alternatives或者独立的软链。解决办法是切换时把两者作为一个整体操作。在update-alternatives里使用--slave把g绑定到gcc组下面就像我在3.1节演示的那样。手动切换脚本里永远同时更新/usr/bin/gcc和/usr/bin/g两个软链。检查当前状态用一行命令同时确认gcc --version | head -n1 g --version | head -n1如果输出里两个版本不一致立即调整。另外gfortran等其它编译器组件也应遵循同样的绑定策略。搞嵌入式交叉编译时交叉版本gcc和g更要严格匹配否则链接阶段会冒出大量undefined reference。5.4 VSCode、MounRiver Studio与Windows下gcc的版本切换把Windows下的多版本gcc问题单独拿出来说是因为它和Linux下的处理逻辑完全不同尤其VSCode里“gcc不是内部或外部命令”这个报错搜索频率一直以来都很高。这个报错本质上就是系统PATH里没有包含gcc所在目录。Windows上第三方工具链通常以MinGW-w64或w64devkit的形式存在解压后目录结构类似E:\mingw64\bin。解决步骤确认gcc实际路径比如E:\mingw64\bin\gcc.exe是否存在。打开系统设置进入环境变量编辑把E:\mingw64\bin追加到PATH的最前面。完全退出VSCode再重新打开让它重新读取环境变量。VSCode里还有一种情况tasks.json中明确指定了编译器命令。如果你在配置里写的是command: g那走的是PATH查找如果写的是command: E:/mingw64/bin/g.exe那就和PATH无关直接使用绝对路径。多版本切换场景下我更推荐在tasks.json里指定绝对路径这样切换版本时只需要改配置不需要动系统PATH。MounRiver Studio这类嵌入式IDE自带一套gcc工具链比如RISC-V交叉编译器riscv-none-embed-gcc。IDE会在内部维护自己的工具链路径配置不建议用系统gcc去替代IDE自带的工具链容易把整个编译流程弄坏。如果你需要在命令行手动使用IDE自带的gcc去IDE安装目录下找toolchain或类似命名的目录把里面的bin路径加入PATH。Windows下管理多个gcc版本我的做法是下载多个MinGW版本把解压目录改成带版本号的名字比如E:\mingw64-13和E:\mingw64-8。需要哪个版本就切换系统PATH或者在IDE里指定对应目录。Windows下没有Linux的update-alternatives这种系统级工具只能用PATH开关或IDE配置来隔离。5.5 编译老项目时新gcc报错这是另一个高频问题不是切换本身出错而是切换到新版gcc之后老项目编译大面积报错。常见原因很简单代码用了旧标准的写法新编译器默认采用更严格的标准和更严的警告。临场处理可以给编译命令加上-fpermissive和-Wno-error前者把一些错误降级为警告后者让警告不中断编译。但这两个选项只是应急不建议长期依赖。根本性的解法有两个方向。短期方案编译时显式指定老标准比如-stdc14或-stdgnu11让新编译器尽可能用老标准的行为去解析代码。长期方案分批修复代码里的旧式写法比如老式C风格转换、缺少头文件包含、隐式类型转换等。修复过程中可以用-Wall -Wpedantic先看看有多少问题逐文件解决。遇到老项目时我个人强烈建议用固定版本gcc的容器来做编译环境而不是在宿主机上反复切换。容器虽然多占一点磁盘空间但能够完整复现某套编译环境不会因为宿主机的环境变化让老项目突然编译失败。6. 关于多版本gcc切换的最终建议写了这么多最后分享几条这几年被反复验证的经验。第一生产服务器上不要频繁切换系统默认gcc。系统自带的gcc往往承担着编译内核模块、系统工具的重要职责你把它切来切去容易影响系统自带软件的运行。正确的做法是把多版本gcc作为独立工具链管理要么放在/usr/local/下要么用SCL隔离需要时显式调用不干扰系统默认配置。第二编译具体项目时优先用CC和CXX变量指定编译器而不是依赖全局切换。比如./configure CC/usr/bin/gcc-10 CXX/usr/bin/g-10或者构建时临时指定make CC/usr/bin/gcc-10 CXX/usr/bin/g-10这种方式只影响当前构建不改变系统全局状态也不影响其他正在工作的终端。特别是服务器上多人共用时全局切换很容易干扰到别人的操作。第三我习惯在系统里放一个自定义命令列出所有可用的gcc版本和当前的默认版本方便随时查阅。一个简单的脚本就能实现#!/bin/bash echo Available gcc versions: ls /usr/bin/gcc-* 2/dev/null | grep -E /gcc-[0-9]$ echo Current default: gcc --version | head -n1 readlink -f /usr/bin/gcc把这段内容保存为/usr/local/bin/gccver并加上执行权限以后任何时候敲一个gccver当前环境的gcc状态一目了然。这种随手就能调用的工具往往比复杂的配置系统更实用。