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_<version>`. > 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
