2

昨天,我尝试通过从源代码构建将我的 gcc 从版本 8.4.0 升级到 9.3.0,因为可以通过 Ubuntu 的 apt repo 安装的最新版本是 8.4.0。

构建和安装过程都可以,我可以编译任何 c++ 代码,即使包括仅由 gcc-9.3.0 实现的功能。但是,如果我在代码中使用了 c++ STL,我将无法运行我的程序。

通过“ ldd my-program”,我发现了问题。看起来 gcc-9.3.0 将文件libstdc++.so.6.0.28安装到/usr/lib64/,而正式版(gcc-8.4.0)的(libstdc++.so.6.0.25)驻留在/usr/lib/x86_64-linux-gnu/中,所以 ld.so 不能为我的程序加载库。如果我将“/usr/lib64”添加到LD_LIBRARY_PATH环境变量中,它就可以工作。

奇怪的是 /usr/lib64 不是 Kubuntu-18.04.4LTS 的 ld.so 的默认搜索位置之一,还是我错了?

我知道它可以通过使用 LD_LIBRARY_PATH 或将路径添加到 /etc/ld.so.conf 来解决,我只是想知道 /usr/lib64 不是默认路径。

此外,我回顾了构建过程:

为了让目标尽可能接近官方的目标,那些来自Ubuntu的apt repo,在配置之前,我用“ echo | gcc -v -x c -E -”获取了官方gcc-8.4.0目标的所有构建选项,然后将它们应用到自己身上建设如下:

~/projects/gcc-9.3.0/configure \
--build=x86_64-linux-gnu \
--disable-libgcj \
--disable-libstdcxx-debug \
--disable-libunwind-exceptions \
--disable-multilib \
--disable-vtable-verify \
--enable-__cxa_atexit \
--enable-bootstrap \
--enable-checking=release \
--enable-clocale=gnu \
--enable-default-pie \
--enable-gnu-indirect-function \
--enable-gnu-unique-object \
--enable-initfini-array \
--enable-languages=c,c++ \
--enable-libmpx \
--enable-libstdcxx-time=yes \
--enable-linker-build-id \
--enable-nls \
--enable-offload-targets=nvptx-none \
--enable-plugin \
--enable-shared \
--enable-threads=posix \
--host=x86_64-linux-gnu \
--libdir=/usr/lib \
--libexecdir=/usr/lib \
--prefix=/usr \
--program-suffix=-9.3 \
--target=x86_64-linux-gnu \
--with-abi=m64 \
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs \
--with-default-libstdcxx-abi=new \
--with-linker-hash-style=gnu \
--with-pkgversion='Ubuntu 9.3.0-6ubuntu1~18.04.4' \
--with-system-zlib \
--with-target-system-zlib \
--with-tune=generic \
--without-cuda-driver \
--without-included-gettext

请注意选项“--libdir=/usr/lib”明确设置了目标库的安装路径。 但是文件 libstdc++.so.6.0.28 最终仍然安装到 /usr/lib64 中。

我错过了什么?

任何帮助或提示将不胜感激!

4

1 回答 1

2

并非所有 Debian/Ubuntu 多架构补丁都已集成到上游 GNU 工具链中。如果要构建与系统其余部分兼容的工具链,则必须手动应用它们。参见源代码包中的debian/patches/gcc-multiarch.diff和。debian/patches/gcc-multilib-multiarch.diffgcc-9

除了多架构路径之外,在动态加载程序中使用的/usr/lib代替/usr/lib64可以追溯到多架构之前的 Debian 端口(例如,Debian 6.0 挤压)和原始 amd64 端口。关于这个问题,有一个非常古老的错误报告和邮件列表讨论:

当时似乎无法为即将发布的 Debian 版本解决此问题,之后就卡住了。(对不起,我不记得细节了。)

于 2020-04-14T20:09:37.463 回答