================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
