This is an archive of the discontinued LLVM Phabricator instance.

Add support to --gcc-toolchain flag for GCC compiled with --enable-version-specific-runtime-libs.
ClosedPublic

Authored by rpenacob on Feb 1 2022, 5:53 AM.

Details

Summary

GCC's compiled with --enable-version-specific-runtime-libs. change the paths where includes and libs are found.
This patch adds support for these cases

Diff Detail

Event Timeline

rpenacob requested review of this revision.Feb 1 2022, 5:53 AM
rpenacob created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 1 2022, 5:53 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
rpenacob updated this revision to Diff 404930.Feb 1 2022, 7:20 AM
MaskRay added a comment.EditedFeb 1 2022, 4:35 PM

Can you dump the gcc search paths (include search paths and -L library search paths) with and without --enable-version-specific-runtime-libs, like the following?

# This is Debian multiarch gcc. See https://maskray.me/blog/2021-03-28-compiler-driver-and-cross-compilation
% gcc a.c -v -xc /dev/null |& sed -E 's/ "?-[iIL]/\n&/
...
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/11/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
...
 -L/usr/lib/gcc/x86_64-linux-gnu/11
 -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu
 -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib
 -L/lib/x86_64-linux-gnu
 -L/lib/../lib
 -L/usr/lib/x86_64-linux-gnu
 -L/usr/lib/../lib
 -L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. /tmp/cc7IN3uz.o ...

For driver tests, it is recommended to test -DCLANG_DEFAULT_CXX_STDLIB=libc++ -DCLANG_DEFAULT_UNWINDLIB=libunwind -DCLANG_DEFAULT_RTLIB=compiler-rt beside the default build to ensure --stdlib= and --rtlib are correctly set.

clang/test/Driver/gcc-toolchain-rt-libs-multi.cpp
2

No need for ( ... ) | .... Just use plain ... 2>&1 | FileCheck ...

7

Consider the form in linux-cross.cpp.

Avoid testing clang. The extra information is not needed and causes trouble to Windows and some build environments where %clang resolves to a file not named clang.

18

no trailing blank line

Sure!

GCC
With the --enable-version-specific-runtime-libs

#include "..." search starts here:
#include <...> search starts here:
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed
 /usr/local/include
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/../../include
 /usr/include
...
-L/home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0
-L/home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc
-L/lib/../lib64
-L/usr/lib/../lib64
-L/home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../..

Without it

#include "..." search starts here:
#include <...> search starts here:
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed
 /usr/local/include
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/../../include
 /usr/include
...
-L/home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0
-L/home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc
-L/home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64
-L/lib/../lib64
-L/usr/lib/../lib64
-L/home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../..

G++
With the --enable-version-specific-runtime-libs

#include "..." search starts here:
#include <...> search starts here:
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/c++
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/c++/x86_64-pc-linux-gnu
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/c++/backward
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed
 /usr/local/include
 /home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/../../include
 /usr/include
...
-L/home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0
-L/home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc
-L/lib/../lib64
-L/usr/lib/../lib64
-L/home/rpenacob/.../gcc-rt-libs/install-rt/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../..

Without it

#include "..." search starts here:
#include <...> search starts here:
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/x86_64-pc-linux-gnu
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/backward
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed
 /usr/local/include
 /home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/../../include
 /usr/include
...
-L/home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0
-L/home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc
-L/home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64
-L/lib/../lib64
-L/usr/lib/../lib64
-L/home/rpenacob/.../gcc-rt-libs/install/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../..

Thanks for the output. Seems like addLibStdCXXIncludePaths is needed, but the addPathIfExists library path seems unnecessary?

That is an interesting case. It looks like we're hitting https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415 , so gcc doesn't seem to search for its own libgcc_s.so when configured with --enable-version-specific-runtime-libs

Most users don't notice this issue because a system-wide libgcc_s.so is usually found instead.

The gcc bug manifests like this:

With --enable-version-specific-runtime-libs
$ <GCC_TOOLCHAIN>/bin/g++ -print-file-name=libgcc_s.so
/lib/../lib64/libgcc_s.so

Without --enable-version-specific-runtime-libs
$ <GCC_TOOLCHAIN>/bin/g++ -print-file-name=libgcc_s.so
<GCC_TOOLCHAIN>/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libgcc_s.so

However clang doesn't get to find the system wide library, so this is why we need an extra library path.

rpenacob updated this revision to Diff 405567.Feb 3 2022, 3:34 AM
MaskRay accepted this revision.Feb 14 2022, 1:10 AM

The library path (lib/gcc/$triple/$libdir) still looks weird and I think I don't understand the GCC rationale well.
If you still think it's the right thing the do, let's do it.

For driver tests involving search paths, it's usually worth checking whether the test passes with -DCLANG_DEFAULT_RTLIB=compiler-rt -DCLANG_DEFAULT_UNWINDLIB=libunwind -DCLANG_DEFAULT_CXX_STDLIB=libc++.
Some groups use this configuration and expect the tests to pass in this mode.

This revision is now accepted and ready to land.Feb 14 2022, 1:10 AM

To test that this change does not break anything we built clang trunk with the patch. Our stage one looks like this.

-DCMAKE_INSTALL_PREFIX=/path/to/stage-one
-DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_PROJECTS=clang
-DLLVM_ENABLE_RUNTIMES="libcxx;compiler-rt;libcxxabi;libunwind"
-DCLANG_DEFAULT_RTLIB=compiler-rt
-DCLANG_DEFAULT_UNWINDLIB=libunwind
-DCLANG_DEFAULT_CXX_STDLIB=libc++
-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON # We don't have multilib for i386 in this test system
-DLLVM_USE_LINKER=lld

Then we built a stage two using the stage one (-DCMAKE_C_COMPILER and -DCMAKE_CXX_COMPILER pointing to stage-one's clang and clang++) with only -DLLVM_ENABLE_PROJECTS=clang. No test failed.

(We had to set LD_LIBRARY_PATH to /path/to/stage-one/lib/x86_64-unknown-linux-gnu so it finds runtime libs like libc++ and such.)

Do you think this is enough testing? Perhaps there is something else we could try.

This revision was landed with ongoing or failed builds.Feb 24 2022, 8:41 PM
This revision was automatically updated to reflect the committed changes.