[clang] [Driver] Fix respecting libdir when locating flang runtime

[mgorny]

Fix tools::addFortranRuntimeLibraryPath to use
CLANG_INSTALL_LIBDIR_BASENAME rather than hardwired lib directory. This fixes flang being unable to find its runtime when installed into nonstandard directory on a system using lib64 for 64-bit libraries. While technically flang runtime could be installed with a different libdir value than clang, it seems rather unlikely.

[llvmbot]

@llvm/pr-subscribers-flang-runtime
@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: Michał Górny (mgorny)

Changes

Fix tools::addFortranRuntimeLibraryPath to use
CLANG_INSTALL_LIBDIR_BASENAME rather than hardwired lib directory. This fixes flang being unable to find its runtime when installed into nonstandard directory on a system using lib64 for 64-bit libraries. While technically flang runtime could be installed with a different libdir value than clang, it seems rather unlikely.

---

Full diff: https://github.com/llvm/llvm-project/pull/127345.diff

1 Files Affected:

• (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+1-1)

diff --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 2d01943ca1ac4..47e6fd9dbf902 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1367,7 +1367,7 @@ void tools::addFortranRuntimeLibraryPath(const ToolChain &TC,
   // lib64 instead of lib.
   SmallString<256> DefaultLibPath =
       llvm::sys::path::parent_path(TC.getDriver().Dir);
-  llvm::sys::path::append(DefaultLibPath, "lib");
+  llvm::sys::path::append(DefaultLibPath, CLANG_INSTALL_LIBDIR_BASENAME);
   if (TC.getTriple().isKnownWindowsMSVCEnvironment())
     CmdArgs.push_back(Args.MakeArgString("-libpath:" + DefaultLibPath));
   else

[MaskRay]

CLANG_INSTALL_LIBDIR_BASENAME can be "lib" or "lib64". I think it should only be used for libraries outside of llvm-project, like how cuda/amdgpu libs are installed by system. For llvm-project installed libs, it's much better to stick with a uniform "lib", which is easy to test in clang/test/Driver %clang -### and avoid platform differences (the test will not break on a different installation just because CLANG_INSTALL_LIBDIR_BASENAME is different).

I am not familiar with offload/cuda/amdgpu. It's possible that CLANG_INSTALL_LIBDIR_BASENAME gets abused (https://reviews.llvm.org/D130586 might be related) in places where it should not be used less.

[mgorny]

But lib is used for 32-bit libraries, and lib64 for 64-bit libraries.

[mgorny]

But lib is used for 32-bit libraries, and lib64 for 64-bit libraries.

…and just to be clear, Flang runtimes are installed into plain system CMAKE_INSTALL_LIBDIR rather than clang/lib/... path (along with the "host" Flang libraries), and they don't have any arch-suffix, so different libdirs is the only way to distinguish 32-bit and 64-bit runtime.

[mgorny]

Hmm, but thinking about it, it should probably grab the right libdir from some multilib config rather than the hardwired build-time value.

[mgorny]

Sigh, looks like clang's driver is a mess around lib/lib64 after all. So a proper solution would probably involve adding arch to the library name, and moving it into clang's resource directory.

[mgorny]

Closed in favor of #134362.