[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
DanielCChen wrote: I am working on a patch that re-uses `compilerRT` code as much as possible. https://github.com/llvm/llvm-project/pull/131041 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
@@ -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
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/131041 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/131041 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/131041 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
Meinersbur wrote: > Right. I tried with `FLANG_RT_ENABLE_SHARED=ON` on AIX. I was able to > dynamically link to the shared `flang-rt` and execute the `a.out` > successfully. With this PR applied? It hardcodes `libflang_rt.runtime.a` on AIX, how can it find the `.so`? > As for buildCompilerRTBasename, it is currently specific to clang_rt with > different Component (e.g. builtins or profile). flang-rt also has components, currently there are `runtime`, `quadmath`, and `cuda_`. > Would you prefer to have a new additional set of functions for flang-rt? I don't find the compiler-rt ones very logical as they have grown over time, especially with the `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` transition. Flang-RT only does `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON` which could simplify some things, but code-reuse of the compiler-rt functions could be worthwhile as well. I would have to experiment to know what works best. Note that the linker currently resolves `-lflang_rt.runtime` because `ToolChain::LibraryPath` (I think) which contains `ToolChain::getRuntimePath()` is added as `-L` argument to the linker. That might be the way to get the location of `flang_rt.*.a`. It would just be nice to have a function that returns the canonical location of `flang_rt.*.a` because currently its all over the place. Also: [multilib](https://github.com/llvm/llvm-project/issues/127538). https://github.com/llvm/llvm-project/pull/131041 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
DanielCChen wrote: > With this PR applied? It hardcodes `libflang_rt.runtime.a` on AIX, how can it > find the `.so`? Sorry, I just realized on AIX, both static and shared library are named `.a`, which is why it didn't fail for me. But it is not the case for other platforms. https://github.com/llvm/llvm-project/pull/131041 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
@@ -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)));
DanielCChen wrote:
> IMHO just doing nothing if the file does exist is a very confusing behavior.
There are some similar usages in the Driver code.
It adds the path to the linker arg list only if the path has been created.
Otherwise, not adding it (i.e. do nothing).
For example, if I didn't have `-DLLVM_ENABLE_RUNTIMES="flang-rt"` specified, I
wouldn't have `build/lib/clang/21/lib/aix/libflang_rt.runtime.a`, so this code
will check that and not adding that to the linker arg list.
That being said, I totally understand your point. Just I don't have a good
answer for it.
https://github.com/llvm/llvm-project/pull/131041
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
https://github.com/Meinersbur commented: This is what I would like to do more generally, not just for AIX. This PR however will break using a shared library libflang_rt.runtime.so. Ideally, we would synchronize with the compiler-rt implementation which already has many supporting functions such as `buildCompilerRTBasename`. https://github.com/llvm/llvm-project/pull/131041 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang-rt] Pass the whole path of libflang_rt.runtime.a to linker on AIX (PR #131041)
@@ -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:
IMHO just doing nothing if the file does exist is a very confusing behavior.
https://github.com/llvm/llvm-project/pull/131041
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
