[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)

Michael Kruse via cfe-commits cfe-commits at lists.llvm.org
Thu Mar 13 02:56:48 PDT 2025


================
@@ -1345,7 +1345,16 @@ void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
       if (AsNeeded)
         addAsNeededOption(TC, Args, CmdArgs, /*as_needed=*/false);
     }
-    CmdArgs.push_back("-lflang_rt.runtime");
+    if (TC.getTriple().isOSAIX()) {
+      // On AIX, pass the whole path of flang_rt.runtime.a to be consistent
+      // with clang.
+      std::string CRTBasename = "libflang_rt.runtime.a";
+      SmallString<128> Path(TC.getCompilerRTPath());
+      llvm::sys::path::append(Path, CRTBasename);
+      if (TC.getVFS().exists(Path))
+        CmdArgs.push_back(Args.MakeArgString(std::string(Path)));
----------------
Meinersbur wrote:

> There are some similar usages in the Driver code.

And its source of one of my biggest grievences. See #122152

If the file does not exist, I want an error message about the file not existing. With the runtime not being added, one will get an error about a symbol not resolved. Someone will have to debug why flang-rt does not define the symbol only to discover that flang-rt is not added to the linker line. Then they have to find out why and the only way I can think of is to find this line in the source that tells them that the flang-rt it not present or in the wrong path. The result of `getCompilerRTPath()` varies by some parameters, or the triple is sligthly different (`x86_64-unknown-linux-gnu` vs `x86_64-linux-gnu`), or ... . I know because I went through this rabbit hole for #122152. Let's please just not do this. 

If the absolute path cannot be resolved, at least add `-lflang_rt.runtime` so the linker can either resolve the library itself, or display an appropriate error.

https://github.com/llvm/llvm-project/pull/131041


More information about the cfe-commits mailing list