1. 问题缘起一个看似简单的依赖缺失最近在Ubuntu 22.04 LTS上折腾一个科学计算项目编译到一半终端突然抛出一个熟悉的错误error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory。这个错误对于在Linux环境下搞过C/C/Fortran混合编程的朋友来说应该不陌生。它意味着系统里缺少了一个关键的Fortran运行时库文件。但有意思的是在Ubuntu 22.04这个相对较新的长期支持版本中这个库的“缺席”并非偶然而是其软件包管理策略变化的一个直接体现。很多从Ubuntu 20.04 LTS升级上来的用户或者按照一些老旧教程操作的朋友很容易在这里卡壳。你可能会想不就是装个库吗apt install一下不就好了但当你真的执行sudo apt install libgfortran3时大概率会收到一个“无法定位软件包”的回复。这就有点让人挠头了一个在众多科学计算、工程仿真软件如R语言的部分扩展包、某些版本的Octave、老版本的GROMACS分子动力学软件等中都被依赖的基础运行时库怎么在新系统里“消失”了呢这篇内容就来彻底拆解这个问题不仅告诉你如何把它装回去更要把背后的原因、不同安装路径的优劣以及后续可能遇到的“坑”都讲明白。2. 核心症结GCC版本迭代与ABI兼容性要理解为什么libgfortran.so.3在Ubuntu 22.04的默认仓库里找不到我们必须先搞懂Linux系统共享库版本命名的规则以及GCCGNU Compiler Collection升级带来的影响。在Linux中共享库Shared Library的文件名通常遵循libname.so.major.minor.patch的格式。其中major主版本号的增加通常意味着应用程序二进制接口ABI发生了不兼容的变更。也就是说如果一个程序是链接libgfortran.so.3编译的那么它就无法在只提供libgfortran.so.4或libgfortran.so.5的系统上直接运行即使后者功能更强大、更现代。Ubuntu 22.04 LTS 默认搭载的GCC版本是11.x系列。而从GCC 4.x时代到GCC 7/8/9其Fortran编译器gfortran生成的代码所依赖的运行时库其主版本号一直是3对应的库文件就是libgfortran.so.3。然而从GCC 10版本开始gfortran运行时库的ABI发生了重大变化主版本号也随之升级。GCC 10/11/12等版本提供的是libgfortran.so.5注意这里跳过了版本4。因此Ubuntu 22.04作为搭载GCC 11的系统其官方仓库jammy中自然只包含了libgfortran5相关的软件包而不再提供老旧的libgfortran3。这本质上是一个向前兼容性的取舍。操作系统发行版为了保持系统的简洁性和维护效率不会无限制地携带所有历史版本的库。它们通常会选择支持当前主要工具链版本所对应的库。这就苦了那些需要运行或编译遗留代码的用户。你的项目或预编译的二进制文件很可能是在一个更老的系统如Ubuntu 18.04 CentOS 7等上用GCC 7或GCC 8编译的因此它坚定地寻找libgfortran.so.3。直接安装libgfortran5是解决不了问题的因为ABI不匹配。那么解决方案的核心思路就清晰了我们需要在Ubuntu 22.04这个“现代化”的系统上为那些“怀旧”的软件提供一个老版本的Fortran运行时库环境。主要有三种路径各有优劣。3. 方案一从Ubuntu旧版本仓库直接安装推荐首选这是最直接、最干净也是我个人最推荐的方法。既然Ubuntu 22.04自己的仓库没有我们就去包含这个库的旧版本仓库里找。Ubuntu 20.04 LTS代号Focal Fossa的仓库里就明确提供了libgfortran-9-dev和libgfortran5但更重要的是它也提供了libgfortran-7-dev和libgfortran3。我们可以临时添加20.04的仓库只安装我们需要的这个特定库。操作步骤如下备份源列表良好的操作习惯sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup临时添加Ubuntu 20.04 (Focal)的软件源 编辑源列表文件在文件末尾添加Focal的main仓库。这里的关键是只添加一行并且明确指定版本避免污染你22.04的主源。echo deb http://archive.ubuntu.com/ubuntu focal main universe | sudo tee -a /etc/apt/sources.list.d/focal-for-libgfortran3.list这里我们创建了一个新的源列表文件focal-for-libgfortran3.list而不是直接修改sources.list这样管理起来更清晰卸载时直接删除这个文件即可。为添加的旧源设置较低的优先级关键步骤 这是防止系统意外从旧源升级其他软件包的核心技巧。我们需要创建APT优先级配置文件。sudo nano /etc/apt/preferences.d/99-focal-pin在该文件中输入以下内容Package: * Pin: release nfocal Pin-Priority: 100这个配置的意思是对于所有软件包Package: *如果来自代号为focal的发布版Pin: release nfocal则将其优先级设置为100。Ubuntu默认源的优先级是500优先级数字越高在安装时被选中的可能性越大。设置为100可以确保除非没有其他选择否则不会从focal源安装或更新任何包。更新软件包列表并安装目标库sudo apt update sudo apt install libgfortran-9-dev/focal注意这里我们安装的是libgfortran-9-dev。你可能会疑惑不是要libgfortran.so.3吗这是因为在Ubuntu的打包体系中libgfortran-9-dev这个包对应GCC 9会同时提供libgfortran.so.3运行时库和开发用的头文件、静态库等。而libgfortran3这个包可能只是一个过渡性的空包或者依赖包。直接安装libgfortran-9-dev/focal/focal指定从focal源安装是最可靠的方式。安装过程中APT会自动处理好libgfortran3的依赖。验证安装 安装完成后可以通过以下命令检查库文件是否存在find /usr/lib /usr/lib/x86_64-linux-gnu -name libgfortran.so.3 2/dev/null或者直接尝试链接ldconfig -p | grep libgfortran.so.3你应该能看到类似libgfortran.so.3 (libc6,x86-64) /usr/lib/x86_64-linux-gnu/libgfortran.so.3的输出。可选清理安装成功后如果你担心源列表混乱可以删除刚才添加的临时源文件并再次更新APT缓存。sudo rm /etc/apt/sources.list.d/focal-for-libgfortran3.list sudo rm /etc/apt/preferences.d/99-focal-pin sudo apt update重要提示即使删除了源文件已经安装的libgfortran-9-dev及其依赖包仍然会保留在系统中正常工作。删除源只是防止未来apt update时再去连接那个不存在的地址。这个方案的优点它利用了官方仓库安全可靠通过APT优先级控制对系统其他部分影响最小安装的库文件路径规范通常在/usr/lib/x86_64-linux-gnu/与系统其他库保持一致。缺点步骤稍多需要理解APT优先级配置。4. 方案二手动下载并安装旧版本Deb包如果觉得修改源列表有心理负担或者网络环境访问特定仓库有问题手动下载.deb安装包也是一个备选方案。我们需要找到适用于Ubuntu 20.04或18.04的libgfortran3或libgfortran-9-dev的deb包。寻找合适的包 访问 https://packages.ubuntu.com/ 这个网站。在搜索框里输入“libgfortran-9-dev”。在结果页面选择“Focal (20.04)”版本。在包详情页找到你系统架构对应的下载链接通常是amd64。下载与安装 在终端中使用wget下载然后用dpkg安装。# 假设我们找到了amd64架构的包 wget http://archive.ubuntu.com/ubuntu/pool/universe/g/gcc-9/libgfortran-9-dev_9.4.0-1ubuntu1~20.04_amd64.deb sudo dpkg -i libgfortran-9-dev_9.4.0-1ubuntu1~20.04_amd64.deb处理依赖问题 手动安装deb包很可能遇到依赖缺失的错误因为dpkg不会自动处理依赖。你会看到类似“依赖关系未满足libgcc-s1 ( 4.2), libgfortran5 ( 8)”的错误。这时你需要根据错误提示递归地去下载并安装所有缺失的依赖包。这个过程可能非常繁琐就像玩一个依赖关系拼图。注意apt命令之所以强大就是因为它能自动解决依赖。手动安装deb包时你可以尝试使用sudo apt-get install -f来修复因手动安装破坏的依赖关系但有时这也会引发意想不到的冲突。这个方案的优点无需修改系统软件源操作相对独立。缺点处理依赖极其麻烦容易出错安装的包可能因为依赖版本问题与系统不完全兼容后续难以通过apt进行统一管理。5. 方案三从源码编译GCC旧版本最重但最可控这是一个“核弹级”的解决方案适用于对环境控制有极致要求或者需要一整套旧版本GCC工具链包括gcc, g, gfortran的场景。例如你需要确保整个编译环境与某个特定生产环境完全一致。这里以编译GCC 9.5.0为例这是一个仍然提供libgfortran.so.3的较新版本。安装编译依赖sudo apt update sudo apt install build-essential wget m4 flex bison libgmp-dev libmpfr-dev libmpc-dev下载GCC源码wget https://ftp.gnu.org/gnu/gcc/gcc-9.5.0/gcc-9.5.0.tar.gz tar -xzf gcc-9.5.0.tar.gz cd gcc-9.5.0下载依赖库 GCC编译需要一些额外的库如isl, cloog等。GCC源码提供了一个脚本来自动下载这些依赖。./contrib/download_prerequisites配置编译选项 为了避免污染系统默认路径我们选择将GCC安装到/opt/gcc-9.5.0目录下。mkdir build cd build ../configure --prefix/opt/gcc-9.5.0 --enable-languagesc,c,fortran --disable-multilib--disable-multilib表示只编译64位库简化过程。编译与安装 这是一个非常耗时的过程取决于你的CPU核心数可能需要数十分钟到几小时。make -j$(nproc) # 使用所有CPU核心并行编译 sudo make install使用自定义的GCC 编译安装后/opt/gcc-9.5.0目录下会有完整的工具链。你可以通过绝对路径来使用它/opt/gcc-9.5.0/bin/gfortran --version这个gfortran编译出的程序自然会链接到它自带的libgfortran.so.3位于/opt/gcc-9.5.0/lib64。为了让系统能找到这个库你需要将该路径添加到动态链接库搜索路径中echo /opt/gcc-9.5.0/lib64 | sudo tee /etc/ld.so.conf.d/gcc-9.5.0.conf sudo ldconfig这个方案的优点环境完全自包含高度可控不影响系统默认工具链。缺点编译耗时极长占用大量磁盘空间配置和使用相对复杂需要手动管理库路径。6. 安装后的验证与常见问题排查无论采用哪种方案安装成功都建议进行以下验证和问题排查确保库真正可用。基础验证# 检查库文件是否存在 ls -l /usr/lib/x86_64-linux-gnu/libgfortran.so.3 # 检查动态链接器缓存 ldconfig -p | grep libgfortran你应该能看到libgfortran.so.3和libgfortran.so.5系统自带都出现在列表中。测试一个简单的Fortran程序 创建一个测试文件test_fortran.f90program hello print *, Hello from Fortran linked against libgfortran.so.3! end program hello使用系统自带的gfortran-11链接libgfortran.so.5和可能通过方案一安装的gfortran-9链接libgfortran.so.3分别编译测试# 使用系统gfortran (GCC 11) gfortran test_fortran.f90 -o test_new ldd test_new | grep libgfortran # 应显示libgfortran.so.5 # 如果你安装了gfortran-9 gfortran-9 test_fortran.f90 -o test_old ldd test_old | grep libgfortran # 应显示libgfortran.so.3运行./test_old如果成功打印信息则证明运行时链接正确。解决“已安装但程序仍找不到”的问题 有时候库安装了但你的程序尤其是那些通过解压二进制包、或从源码make install到/usr/local的程序可能还在其他路径寻找。你可以通过以下方式检查并解决检查程序自身的依赖ldd /path/to/your/program | grep not found添加库路径如果程序在非标准路径如/opt/your_app/lib下寻找libgfortran.so.3你有几种选择 a. 将库文件软链接到程序寻找的目录sudo ln -s /usr/lib/x86_64-linux-gnu/libgfortran.so.3 /opt/your_app/lib/b. 在运行程序前设置LD_LIBRARY_PATH环境变量临时生效export LD_LIBRARY_PATH/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH ./your_programc. 将库路径永久添加到系统配置中如我们之前在方案三所做编辑/etc/ld.so.conf.d/下的文件并运行sudo ldconfig。多版本库共存时的优先级问题 系统同时存在libgfortran.so.3和libgfortran.so.5是正常的。动态链接器ld.so会根据程序编译时记录的依赖信息DT_NEEDED来加载对应版本的库。它们通过不同的文件名libgfortran.so.3vslibgfortran.so.5区分互不干扰。不会出现“该用版本3却错误链接了版本5”的情况因为文件名本身就决定了它们是不同的库。7. 深入思考如何避免和长效管理此类问题搞定一次依赖缺失是“救火”建立好的开发习惯才是“防火”。结合这次libgfortran.so.3的安装经历分享几点我的体会对于软件使用者尤其是科学计算领域优先选择容器化方案如果你要运行的软件有复杂的、陈旧的依赖强烈建议使用Docker或Singularity。开发者可以提供一个包含所有依赖的完整镜像例如基于Ubuntu 18.04或CentOS 7你只需要安装Docker引擎然后一条命令就能获得一个完全一致、隔离的环境彻底摆脱“依赖地狱”。这是目前学术界和工业界解决环境问题的事实标准。利用 Conda/Mamba 环境对于Python生态的科学计算包Conda和Mamba不仅是包管理器也能管理二进制依赖。像libgfortran这样的系统级库可以通过conda install libgfortran来安装Conda会将其安装到独立的环境目录中不会影响系统全局库。很多科学软件如R的r-base包在Conda通道中都有提供它们会自动处理好这些底层依赖。留意软件的发布说明在下载或编译一个软件前花几分钟阅读其官方文档的“Installation”或“Requirements”部分。它通常会明确指出需要的编译器版本、依赖库及其版本。如果它要求GCC 10那你就要提前对libgfortran.so.3有所准备。对于软件开发者明确声明依赖在项目的README或构建脚本中清晰说明所需的编译器最低版本、以及关键的系统库如libgfortran版本。更好的做法是提供Dockerfile或environment.ymlConda文件来定义可复现的环境。考虑使用静态链接对于发布给终端用户使用的二进制程序如果依赖关系复杂可以考虑将libgfortran等运行时库静态链接到可执行文件中。这样生成的二进制文件体积会变大但几乎可以在任何同架构的Linux系统上运行无需担心目标系统的库版本。使用gfortran编译时可以尝试添加-static-libgfortran选项注意完全静态链接可能需要-static但会涉及更多库如glibc通常不推荐。瞄准主流发行版的LTS版本如果你的软件用户群体广泛建议针对主流发行版的最新LTS版本如Ubuntu 22.04/24.04 LTS, RHEL 9等进行主要支持和测试。这能确保你的软件与大多数用户的基础系统兼容或者至少能明确知道不兼容的边界在哪里。回过头看在Ubuntu 22.04上安装libgfortran.so.3更像是一个系统演进与软件遗产之间矛盾的缩影。方案一添加旧源并设置优先级是我在大多数生产环境中的首选它在系统整洁性和解决问题之间取得了很好的平衡。理解其背后的ABI版本原理能帮助你在遇到类似libstdc.so.6版本过低等问题时举一反三。最后拥抱容器化等现代部署方式能让你从无穷尽的依赖配置中解放出来把精力更多地集中在项目本身。 
长河君 · 2026/8/11 6:34:36 · 阅读 1.2k Ubuntu 22.04安装libgfortran.so.3：解决GCC版本兼容性问题
1. 问题缘起一个看似简单的依赖缺失最近在Ubuntu 22.04 LTS上折腾一个科学计算项目编译到一半终端突然抛出一个熟悉的错误error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory。这个错误对于在Linux环境下搞过C/C/Fortran混合编程的朋友来说应该不陌生。它意味着系统里缺少了一个关键的Fortran运行时库文件。但有意思的是在Ubuntu 22.04这个相对较新的长期支持版本中这个库的“缺席”并非偶然而是其软件包管理策略变化的一个直接体现。很多从Ubuntu 20.04 LTS升级上来的用户或者按照一些老旧教程操作的朋友很容易在这里卡壳。你可能会想不就是装个库吗apt install一下不就好了但当你真的执行sudo apt install libgfortran3时大概率会收到一个“无法定位软件包”的回复。这就有点让人挠头了一个在众多科学计算、工程仿真软件如R语言的部分扩展包、某些版本的Octave、老版本的GROMACS分子动力学软件等中都被依赖的基础运行时库怎么在新系统里“消失”了呢这篇内容就来彻底拆解这个问题不仅告诉你如何把它装回去更要把背后的原因、不同安装路径的优劣以及后续可能遇到的“坑”都讲明白。2. 核心症结GCC版本迭代与ABI兼容性要理解为什么libgfortran.so.3在Ubuntu 22.04的默认仓库里找不到我们必须先搞懂Linux系统共享库版本命名的规则以及GCCGNU Compiler Collection升级带来的影响。在Linux中共享库Shared Library的文件名通常遵循libname.so.major.minor.patch的格式。其中major主版本号的增加通常意味着应用程序二进制接口ABI发生了不兼容的变更。也就是说如果一个程序是链接libgfortran.so.3编译的那么它就无法在只提供libgfortran.so.4或libgfortran.so.5的系统上直接运行即使后者功能更强大、更现代。Ubuntu 22.04 LTS 默认搭载的GCC版本是11.x系列。而从GCC 4.x时代到GCC 7/8/9其Fortran编译器gfortran生成的代码所依赖的运行时库其主版本号一直是3对应的库文件就是libgfortran.so.3。然而从GCC 10版本开始gfortran运行时库的ABI发生了重大变化主版本号也随之升级。GCC 10/11/12等版本提供的是libgfortran.so.5注意这里跳过了版本4。因此Ubuntu 22.04作为搭载GCC 11的系统其官方仓库jammy中自然只包含了libgfortran5相关的软件包而不再提供老旧的libgfortran3。这本质上是一个向前兼容性的取舍。操作系统发行版为了保持系统的简洁性和维护效率不会无限制地携带所有历史版本的库。它们通常会选择支持当前主要工具链版本所对应的库。这就苦了那些需要运行或编译遗留代码的用户。你的项目或预编译的二进制文件很可能是在一个更老的系统如Ubuntu 18.04 CentOS 7等上用GCC 7或GCC 8编译的因此它坚定地寻找libgfortran.so.3。直接安装libgfortran5是解决不了问题的因为ABI不匹配。那么解决方案的核心思路就清晰了我们需要在Ubuntu 22.04这个“现代化”的系统上为那些“怀旧”的软件提供一个老版本的Fortran运行时库环境。主要有三种路径各有优劣。3. 方案一从Ubuntu旧版本仓库直接安装推荐首选这是最直接、最干净也是我个人最推荐的方法。既然Ubuntu 22.04自己的仓库没有我们就去包含这个库的旧版本仓库里找。Ubuntu 20.04 LTS代号Focal Fossa的仓库里就明确提供了libgfortran-9-dev和libgfortran5但更重要的是它也提供了libgfortran-7-dev和libgfortran3。我们可以临时添加20.04的仓库只安装我们需要的这个特定库。操作步骤如下备份源列表良好的操作习惯sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup临时添加Ubuntu 20.04 (Focal)的软件源 编辑源列表文件在文件末尾添加Focal的main仓库。这里的关键是只添加一行并且明确指定版本避免污染你22.04的主源。echo deb http://archive.ubuntu.com/ubuntu focal main universe | sudo tee -a /etc/apt/sources.list.d/focal-for-libgfortran3.list这里我们创建了一个新的源列表文件focal-for-libgfortran3.list而不是直接修改sources.list这样管理起来更清晰卸载时直接删除这个文件即可。为添加的旧源设置较低的优先级关键步骤 这是防止系统意外从旧源升级其他软件包的核心技巧。我们需要创建APT优先级配置文件。sudo nano /etc/apt/preferences.d/99-focal-pin在该文件中输入以下内容Package: * Pin: release nfocal Pin-Priority: 100这个配置的意思是对于所有软件包Package: *如果来自代号为focal的发布版Pin: release nfocal则将其优先级设置为100。Ubuntu默认源的优先级是500优先级数字越高在安装时被选中的可能性越大。设置为100可以确保除非没有其他选择否则不会从focal源安装或更新任何包。更新软件包列表并安装目标库sudo apt update sudo apt install libgfortran-9-dev/focal注意这里我们安装的是libgfortran-9-dev。你可能会疑惑不是要libgfortran.so.3吗这是因为在Ubuntu的打包体系中libgfortran-9-dev这个包对应GCC 9会同时提供libgfortran.so.3运行时库和开发用的头文件、静态库等。而libgfortran3这个包可能只是一个过渡性的空包或者依赖包。直接安装libgfortran-9-dev/focal/focal指定从focal源安装是最可靠的方式。安装过程中APT会自动处理好libgfortran3的依赖。验证安装 安装完成后可以通过以下命令检查库文件是否存在find /usr/lib /usr/lib/x86_64-linux-gnu -name libgfortran.so.3 2/dev/null或者直接尝试链接ldconfig -p | grep libgfortran.so.3你应该能看到类似libgfortran.so.3 (libc6,x86-64) /usr/lib/x86_64-linux-gnu/libgfortran.so.3的输出。可选清理安装成功后如果你担心源列表混乱可以删除刚才添加的临时源文件并再次更新APT缓存。sudo rm /etc/apt/sources.list.d/focal-for-libgfortran3.list sudo rm /etc/apt/preferences.d/99-focal-pin sudo apt update重要提示即使删除了源文件已经安装的libgfortran-9-dev及其依赖包仍然会保留在系统中正常工作。删除源只是防止未来apt update时再去连接那个不存在的地址。这个方案的优点它利用了官方仓库安全可靠通过APT优先级控制对系统其他部分影响最小安装的库文件路径规范通常在/usr/lib/x86_64-linux-gnu/与系统其他库保持一致。缺点步骤稍多需要理解APT优先级配置。4. 方案二手动下载并安装旧版本Deb包如果觉得修改源列表有心理负担或者网络环境访问特定仓库有问题手动下载.deb安装包也是一个备选方案。我们需要找到适用于Ubuntu 20.04或18.04的libgfortran3或libgfortran-9-dev的deb包。寻找合适的包 访问 https://packages.ubuntu.com/ 这个网站。在搜索框里输入“libgfortran-9-dev”。在结果页面选择“Focal (20.04)”版本。在包详情页找到你系统架构对应的下载链接通常是amd64。下载与安装 在终端中使用wget下载然后用dpkg安装。# 假设我们找到了amd64架构的包 wget http://archive.ubuntu.com/ubuntu/pool/universe/g/gcc-9/libgfortran-9-dev_9.4.0-1ubuntu1~20.04_amd64.deb sudo dpkg -i libgfortran-9-dev_9.4.0-1ubuntu1~20.04_amd64.deb处理依赖问题 手动安装deb包很可能遇到依赖缺失的错误因为dpkg不会自动处理依赖。你会看到类似“依赖关系未满足libgcc-s1 ( 4.2), libgfortran5 ( 8)”的错误。这时你需要根据错误提示递归地去下载并安装所有缺失的依赖包。这个过程可能非常繁琐就像玩一个依赖关系拼图。注意apt命令之所以强大就是因为它能自动解决依赖。手动安装deb包时你可以尝试使用sudo apt-get install -f来修复因手动安装破坏的依赖关系但有时这也会引发意想不到的冲突。这个方案的优点无需修改系统软件源操作相对独立。缺点处理依赖极其麻烦容易出错安装的包可能因为依赖版本问题与系统不完全兼容后续难以通过apt进行统一管理。5. 方案三从源码编译GCC旧版本最重但最可控这是一个“核弹级”的解决方案适用于对环境控制有极致要求或者需要一整套旧版本GCC工具链包括gcc, g, gfortran的场景。例如你需要确保整个编译环境与某个特定生产环境完全一致。这里以编译GCC 9.5.0为例这是一个仍然提供libgfortran.so.3的较新版本。安装编译依赖sudo apt update sudo apt install build-essential wget m4 flex bison libgmp-dev libmpfr-dev libmpc-dev下载GCC源码wget https://ftp.gnu.org/gnu/gcc/gcc-9.5.0/gcc-9.5.0.tar.gz tar -xzf gcc-9.5.0.tar.gz cd gcc-9.5.0下载依赖库 GCC编译需要一些额外的库如isl, cloog等。GCC源码提供了一个脚本来自动下载这些依赖。./contrib/download_prerequisites配置编译选项 为了避免污染系统默认路径我们选择将GCC安装到/opt/gcc-9.5.0目录下。mkdir build cd build ../configure --prefix/opt/gcc-9.5.0 --enable-languagesc,c,fortran --disable-multilib--disable-multilib表示只编译64位库简化过程。编译与安装 这是一个非常耗时的过程取决于你的CPU核心数可能需要数十分钟到几小时。make -j$(nproc) # 使用所有CPU核心并行编译 sudo make install使用自定义的GCC 编译安装后/opt/gcc-9.5.0目录下会有完整的工具链。你可以通过绝对路径来使用它/opt/gcc-9.5.0/bin/gfortran --version这个gfortran编译出的程序自然会链接到它自带的libgfortran.so.3位于/opt/gcc-9.5.0/lib64。为了让系统能找到这个库你需要将该路径添加到动态链接库搜索路径中echo /opt/gcc-9.5.0/lib64 | sudo tee /etc/ld.so.conf.d/gcc-9.5.0.conf sudo ldconfig这个方案的优点环境完全自包含高度可控不影响系统默认工具链。缺点编译耗时极长占用大量磁盘空间配置和使用相对复杂需要手动管理库路径。6. 安装后的验证与常见问题排查无论采用哪种方案安装成功都建议进行以下验证和问题排查确保库真正可用。基础验证# 检查库文件是否存在 ls -l /usr/lib/x86_64-linux-gnu/libgfortran.so.3 # 检查动态链接器缓存 ldconfig -p | grep libgfortran你应该能看到libgfortran.so.3和libgfortran.so.5系统自带都出现在列表中。测试一个简单的Fortran程序 创建一个测试文件test_fortran.f90program hello print *, Hello from Fortran linked against libgfortran.so.3! end program hello使用系统自带的gfortran-11链接libgfortran.so.5和可能通过方案一安装的gfortran-9链接libgfortran.so.3分别编译测试# 使用系统gfortran (GCC 11) gfortran test_fortran.f90 -o test_new ldd test_new | grep libgfortran # 应显示libgfortran.so.5 # 如果你安装了gfortran-9 gfortran-9 test_fortran.f90 -o test_old ldd test_old | grep libgfortran # 应显示libgfortran.so.3运行./test_old如果成功打印信息则证明运行时链接正确。解决“已安装但程序仍找不到”的问题 有时候库安装了但你的程序尤其是那些通过解压二进制包、或从源码make install到/usr/local的程序可能还在其他路径寻找。你可以通过以下方式检查并解决检查程序自身的依赖ldd /path/to/your/program | grep not found添加库路径如果程序在非标准路径如/opt/your_app/lib下寻找libgfortran.so.3你有几种选择 a. 将库文件软链接到程序寻找的目录sudo ln -s /usr/lib/x86_64-linux-gnu/libgfortran.so.3 /opt/your_app/lib/b. 在运行程序前设置LD_LIBRARY_PATH环境变量临时生效export LD_LIBRARY_PATH/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH ./your_programc. 将库路径永久添加到系统配置中如我们之前在方案三所做编辑/etc/ld.so.conf.d/下的文件并运行sudo ldconfig。多版本库共存时的优先级问题 系统同时存在libgfortran.so.3和libgfortran.so.5是正常的。动态链接器ld.so会根据程序编译时记录的依赖信息DT_NEEDED来加载对应版本的库。它们通过不同的文件名libgfortran.so.3vslibgfortran.so.5区分互不干扰。不会出现“该用版本3却错误链接了版本5”的情况因为文件名本身就决定了它们是不同的库。7. 深入思考如何避免和长效管理此类问题搞定一次依赖缺失是“救火”建立好的开发习惯才是“防火”。结合这次libgfortran.so.3的安装经历分享几点我的体会对于软件使用者尤其是科学计算领域优先选择容器化方案如果你要运行的软件有复杂的、陈旧的依赖强烈建议使用Docker或Singularity。开发者可以提供一个包含所有依赖的完整镜像例如基于Ubuntu 18.04或CentOS 7你只需要安装Docker引擎然后一条命令就能获得一个完全一致、隔离的环境彻底摆脱“依赖地狱”。这是目前学术界和工业界解决环境问题的事实标准。利用 Conda/Mamba 环境对于Python生态的科学计算包Conda和Mamba不仅是包管理器也能管理二进制依赖。像libgfortran这样的系统级库可以通过conda install libgfortran来安装Conda会将其安装到独立的环境目录中不会影响系统全局库。很多科学软件如R的r-base包在Conda通道中都有提供它们会自动处理好这些底层依赖。留意软件的发布说明在下载或编译一个软件前花几分钟阅读其官方文档的“Installation”或“Requirements”部分。它通常会明确指出需要的编译器版本、依赖库及其版本。如果它要求GCC 10那你就要提前对libgfortran.so.3有所准备。对于软件开发者明确声明依赖在项目的README或构建脚本中清晰说明所需的编译器最低版本、以及关键的系统库如libgfortran版本。更好的做法是提供Dockerfile或environment.ymlConda文件来定义可复现的环境。考虑使用静态链接对于发布给终端用户使用的二进制程序如果依赖关系复杂可以考虑将libgfortran等运行时库静态链接到可执行文件中。这样生成的二进制文件体积会变大但几乎可以在任何同架构的Linux系统上运行无需担心目标系统的库版本。使用gfortran编译时可以尝试添加-static-libgfortran选项注意完全静态链接可能需要-static但会涉及更多库如glibc通常不推荐。瞄准主流发行版的LTS版本如果你的软件用户群体广泛建议针对主流发行版的最新LTS版本如Ubuntu 22.04/24.04 LTS, RHEL 9等进行主要支持和测试。这能确保你的软件与大多数用户的基础系统兼容或者至少能明确知道不兼容的边界在哪里。回过头看在Ubuntu 22.04上安装libgfortran.so.3更像是一个系统演进与软件遗产之间矛盾的缩影。方案一添加旧源并设置优先级是我在大多数生产环境中的首选它在系统整洁性和解决问题之间取得了很好的平衡。理解其背后的ABI版本原理能帮助你在遇到类似libstdc.so.6版本过低等问题时举一反三。最后拥抱容器化等现代部署方式能让你从无穷尽的依赖配置中解放出来把精力更多地集中在项目本身。