Yestoday, I tried to upgrade my gcc from version 8.4.0 to 9.3.0 by building from source, because the latest version that can be installed through apt repo of Ubuntu, is 8.4.0.
Building and installing proccesses are all OK, and I can compile whatever c++ code even though including the features those are implemented only by gcc-9.3.0. But I can NOT run my programs, if I used c++ STL in my code.
By means of "ldd my-program", I found the problem.
It looks like that gcc-9.3.0 installed the file libstdc++.so.6.0.28 into /usr/lib64/, while the one(libstdc++.so.6.0.25) of the official version(gcc-8.4.0) resides in /usr/lib/x86_64-linux-gnu/, so ld.so can NOT load libs for my-program.
If I add "/usr/lib64" into LD_LIBRARY_PATH env var, it works.
It's strange that /usr/lib64 is NOT the one of the default searching locations of ld.so of Kubuntu-18.04.4LTS, or I am wrong?
I know it can be resolved by using LD_LIBRARY_PATH or add path into /etc/ld.so.conf, I'm just wondering /usr/lib64 is NOT the default path.
Additionally, I reviewed the building proccess:
In order to make the targets as close as possible to the official targets those come from Ubuntu's apt repo,
before configuring, I used "echo | gcc -v -x c -E -" to get all the build options of the official gcc-8.4.0 targets,
and then apply them to myself buiding as following:
~/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
Pls note the option "--libdir=/usr/lib" explicitly sets the path to which the target-libs should be installed. But the file libstdc++.so.6.0.28 was still installed to /usr/lib64 finally.
What things did I missed?
Any help or hint will be appretiated!
Not all the Debian/Ubuntu multiarch patches have been integrated into the upstream GNU toolchain. If you want to build a toolchain compatible with the rest of the system, you will have to apply them manually. See debian/patches/gcc-multiarch.diff and debian/patches/gcc-multilib-multiarch.diff in the gcc-9 source package.
Use of /usr/lib instead of /usr/lib64 in the dynamic loader, in addition to the multi-arch paths, goes back to the pre-multi-arch Debian ports (e.g., Debian 6.0 squeeze) and the original amd64 port. There is a very old bug report and mailing list discussion about this very matter:
It seems that this could not be fixed for the upcoming Debian release at the time, and got stuck afterwards. (Sorry, I do not remember the details.)