DanielCChen wrote: > Can you please explain why you want to link the static library by default? > For example, Clang has these options > https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-static-libgcc > that allow users to force the static linking, and, I think, by default it > links shared compiler support libraries. > > Also, how does the full path linking of the shared library works with > `-frtlib-add-rpath`?
The `flang-rt` cmake is using the similar frame work to how `compiler-rt` is built. It publishes `libflang_rt.runtime.*` to the Clang `resource_dir` no matter if it is static or shared although `resource_dir` is normally for static libs. As your link points out, unlike Clang, Flang currently does not have a compiler option to switch between linking to the static or shared `flang-rt`, so the current order in this PR does not dictate the default. As the next step, I am planning to add a compiler option `-static-libflang_rt` that is similar to `-static-libgcc` for that purpose (or `-dynamic-libflang_rt` if we decide to link static `flang-rt` as default). As for the `frtlib-add-rpath`, The current code before this PR is passing `-L/resource_dir/ -lflan_rt.runtime` to the linker. If the shared `flang-rt` is present in the `resource_dir`, the linker "prefers" the shared `flang-rt`. Users will need to specify `-frtlib-add-rpath` in order to link to the shared `flang-rt`. The full path linking should not affect that behavior. Users still need the `-frtlib-add-rpath` option to link to the shared `flang-rt` with full path name. I actually missed that in the shared path in this PR. I will push an amendment. https://github.com/llvm/llvm-project/pull/134362 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
