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系统共享库版本命名的规则，以及GCC（GNU Compiler Collection）升级带来的影响。

在Linux中，共享库（Shared Library）的文件名通常遵循lib<name>.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的仓库，只安装我们需要的这个特定库。

操作步骤如下：

1. 备份源列表（良好的操作习惯）：

   sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup

2. 临时添加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，这样管理起来更清晰，卸载时直接删除这个文件即可。

3. 为添加的旧源设置较低的优先级（关键步骤）： 这是防止系统意外从旧源升级其他软件包的核心技巧。我们需要创建APT优先级配置文件。

   sudo nano /etc/apt/preferences.d/99-focal-pin

   在该文件中输入以下内容：

   Package: * Pin: release n=focal Pin-Priority: 100

   这个配置的意思是：对于所有软件包（Package: *），如果来自代号为focal的发布版（Pin: release n=focal），则将其优先级设置为100。Ubuntu默认源的优先级是500，优先级数字越高，在安装时被选中的可能性越大。设置为100可以确保除非没有其他选择，否则不会从focal源安装或更新任何包。

4. 更新软件包列表并安装目标库：

   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的依赖。

5. 验证安装： 安装完成后，可以通过以下命令检查库文件是否存在：

   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的输出。

6. （可选）清理：安装成功后，如果你担心源列表混乱，可以删除刚才添加的临时源文件，并再次更新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包。

1. 寻找合适的包： 访问 https://packages.ubuntu.com/ 这个网站。在搜索框里输入“libgfortran-9-dev”。在结果页面，选择“Focal (20.04)”版本。在包详情页，找到你系统架构对应的下载链接（通常是amd64）。

2. 下载与安装： 在终端中使用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

3. 处理依赖问题： 手动安装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的较新版本。

1. 安装编译依赖：

   sudo apt update sudo apt install build-essential wget m4 flex bison libgmp-dev libmpfr-dev libmpc-dev

2. 下载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

3. 下载依赖库： GCC编译需要一些额外的库，如isl, cloog等。GCC源码提供了一个脚本来自动下载这些依赖。

   ./contrib/download_prerequisites

4. 配置编译选项： 为了避免污染系统默认路径，我们选择将GCC安装到/opt/gcc-9.5.0目录下。

   mkdir build && cd build ../configure --prefix=/opt/gcc-9.5.0 --enable-languages=c,c++,fortran --disable-multilib

   --disable-multilib表示只编译64位库，简化过程。

5. 编译与安装： 这是一个非常耗时的过程，取决于你的CPU核心数，可能需要数十分钟到几小时。

   make -j$(nproc) # 使用所有CPU核心并行编译 sudo make install

6. 使用自定义的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. 安装后的验证与常见问题排查

无论采用哪种方案安装成功，都建议进行以下验证和问题排查，确保库真正可用。

1. 基础验证：

   # 检查库文件是否存在 ls -l /usr/lib/x86_64-linux-gnu/libgfortran.so.3 # 检查动态链接器缓存 ldconfig -p | grep libgfortran

   你应该能看到libgfortran.so.3和libgfortran.so.5（系统自带）都出现在列表中。

2. 测试一个简单的Fortran程序： 创建一个测试文件test_fortran.f90：

   program 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，如果成功打印信息，则证明运行时链接正确。

3. 解决“已安装但程序仍找不到”的问题： 有时候库安装了，但你的程序（尤其是那些通过解压二进制包、或从源码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_program

     c. 将库路径永久添加到系统配置中（如我们之前在方案三所做），编辑/etc/ld.so.conf.d/下的文件并运行sudo ldconfig。

4. 多版本库共存时的优先级问题： 系统同时存在libgfortran.so.3和libgfortran.so.5是正常的。动态链接器ld.so会根据程序编译时记录的依赖信息（DT_NEEDED）来加载对应版本的库。它们通过不同的文件名（libgfortran.so.3vslibgfortran.so.5）区分，互不干扰。不会出现“该用版本3却错误链接了版本5”的情况，因为文件名本身就决定了它们是不同的库。

7. 深入思考：如何避免和长效管理此类问题

搞定一次依赖缺失是“救火”，建立好的开发习惯才是“防火”。结合这次libgfortran.so.3的安装经历，分享几点我的体会：

对于软件使用者（尤其是科学计算领域）：

1. 优先选择容器化方案：如果你要运行的软件有复杂的、陈旧的依赖，强烈建议使用Docker或Singularity。开发者可以提供一个包含所有依赖的完整镜像（例如基于Ubuntu 18.04或CentOS 7），你只需要安装Docker引擎，然后一条命令就能获得一个完全一致、隔离的环境，彻底摆脱“依赖地狱”。这是目前学术界和工业界解决环境问题的事实标准。
2. 利用 Conda/Mamba 环境：对于Python生态的科学计算包，Conda和Mamba不仅是包管理器，也能管理二进制依赖。像libgfortran这样的系统级库，可以通过conda install libgfortran来安装，Conda会将其安装到独立的环境目录中，不会影响系统全局库。很多科学软件（如R的r-base包）在Conda通道中都有提供，它们会自动处理好这些底层依赖。
3. 留意软件的发布说明：在下载或编译一个软件前，花几分钟阅读其官方文档的“Installation”或“Requirements”部分。它通常会明确指出需要的编译器版本、依赖库及其版本。如果它要求GCC < 10，那你就要提前对libgfortran.so.3有所准备。

对于软件开发者：

1. 明确声明依赖：在项目的README或构建脚本中，清晰说明所需的编译器最低版本、以及关键的系统库（如libgfortran）版本。更好的做法是提供Dockerfile或environment.yml（Conda）文件来定义可复现的环境。
2. 考虑使用静态链接：对于发布给终端用户使用的二进制程序，如果依赖关系复杂，可以考虑将libgfortran等运行时库静态链接到可执行文件中。这样生成的二进制文件体积会变大，但几乎可以在任何同架构的Linux系统上运行，无需担心目标系统的库版本。使用gfortran编译时，可以尝试添加-static-libgfortran选项（注意，完全静态链接可能需要-static，但会涉及更多库，如glibc，通常不推荐）。
3. 瞄准主流发行版的LTS版本：如果你的软件用户群体广泛，建议针对主流发行版的最新LTS版本（如Ubuntu 22.04/24.04 LTS, RHEL 9等）进行主要支持和测试。这能确保你的软件与大多数用户的基础系统兼容，或者至少能明确知道不兼容的边界在哪里。

回过头看，在Ubuntu 22.04上安装libgfortran.so.3，更像是一个系统演进与软件遗产之间矛盾的缩影。方案一（添加旧源并设置优先级）是我在大多数生产环境中的首选，它在系统整洁性和解决问题之间取得了很好的平衡。理解其背后的ABI版本原理，能帮助你在遇到类似libstdc++.so.6版本过低等问题时，举一反三。最后，拥抱容器化等现代部署方式，能让你从无穷尽的依赖配置中解放出来，把精力更多地集中在项目本身。