c - 将 Linux 内核升级到最新的 64 位是否会更改 glibc？

Question

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

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

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

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

谢谢

道格

Answer 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 /]#

但是 chroot 环境(用于构建)是 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 位。当然，这不是最快的方法；-)，但它几乎可以无缝实现，不会出现长时间停机或软件版本或行为发生意外变化的情况。当然，您的里程可能会有所不同，您应该仔细检查您的条件、环境等等。