将 Linux 内核升级到最新的 64 位是否会改变 glibc？答案

【问题标题】：Does upgrading a Linux kernel to the latest 64-bit change glibc?将 Linux 内核升级到最新的 64 位是否会改变 glibc？
【发布时间】：2014-04-21 01:12:01
【问题描述】：

在 Linode，我们一直在进行升级以利用他们的新 SSD 驱动器。我们在较旧的 Ubuntu 10.10 32 位系统上运行。

为了进行新的升级，我们一直在将内核从 32 位更改为“最新的 64 位”。到目前为止，这一直运行良好（我们正在运行的 32 位软件很高兴在 64 位内核中运行），但我想知道这是否会改变 glibc。我唯一可能担心的 Linode 是一个 Linode，我们使用 C 编译器构建软件，我还不一定想更改构建时使用的 glibc 版本。

是的，我知道我们应该将实际发行版升级到更新的 64 位 Ubuntu，但这是一个更大的项目，我们还没有准备好去做。所以目前我们只想使用最新的 64 位内核运行，因为它似乎没有造成任何伤害。我们目前只关心从 C 源创建构建对 glibc 的影响。

当然，如果有人知道运行 64 位内核的任何其他缺点，请随时畅所欲言！

谢谢，

道格

【问题讨论】：

不，它没有。基本上一个软件包需要一组库，包括该软件的位数的libc。您可以在二进制文件上运行 ldd 并查看它所链接的库的完整列表。

标签： c linux linux-kernel

【解决方案1】：

看看这个例子：

64 位系统：

 alex@rhyme ~/RPM $ ldd /bin/ls  
    linux-vdso.so.1 (0x00007fffef200000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f4b7b9d8000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f4b7b7b0000)
    libcap.so.2 => /lib64/libcap.so.2 (0x00007f4b7b5a8000)
    libacl.so.1 => /lib64/libacl.so.1 (0x00007f4b7b398000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f4b7afe8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f4b7bc30000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f4b7ade0000)
    libpcre.so.3 => /lib64/libpcre.so.3 (0x00007f4b7ab98000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00007f4b7a990000)
alex@rhyme ~/RPM $  sudo chroot hsh/chroot/ /bin/bash
[sudo] password for alex:
[root@rhyme /]#

但是 chrooted 环境（用于构建）是 32 位的：

[root@rhyme /]# ldd /bin/ls
    linux-gate.so.1 (0xf7752000)
    libtinfo.so.5 => /lib/libtinfo.so.5 (0xf76f8000)
    libselinux.so.1 => /lib/libselinux.so.1 (0xf76d0000)
    libcap.so.2 => /lib/libcap.so.2 (0xf76c8000)
    libacl.so.1 => /lib/libacl.so.1 (0xf76b8000)
    libc.so.6 => /lib/libc.so.6 (0xf7540000)
    /lib/ld-linux.so.2 (0xf7730000)
    libpcre.so.3 => /lib/libpcre.so.3 (0xf74f8000)
    libdl.so.2 => /lib/libdl.so.2 (0xf74f0000)
    libattr.so.1 => /lib/libattr.so.1 (0xf74e8000)
[root@rhyme /]#

注意 ldd 输出的差异。 coreutils（和ls）的版本基本相同。

据我所知，使用 64 位内核可能有一个缺点。在 64 位模式下，内核本身和控制结构需要更多的内存（内核代码指令是 64 位的）。除此之外，我没有注意到这种配置有任何问题。

顺便说一句，运行 32 和 64 个二进制文件和库共存的系统在一个系统中称为多架构（在上面的示例中，没有多架构，因为第二个系统有自己的，我已经 chroot 的单独文件系统）。据我所知，Debian 和 Ubuntu 都具有可行的多架构支持，apt 的单个实例可以完美地管理 32 位和 64 位软件包集。

因此，理论上您可以进行“缓慢迁移”，只需在 32 位对应库旁边安装 64 位库，然后将 32 位到 64 位的二进制文件一一替换。当然，这不会是最快的方式 ;-) 但它可以实现几乎无缝，没有长时间的停机或软件版本或行为的意外更改。当然你的里程可能会有所不同，你应该仔细检查你的条件、环境等等。

【讨论】：