[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