Parse implicit link information for this compiler to support
mixed-language linking. This was missed by commit 98d0f918ba (LFortran:
Add support for this compiler, 2024-01-25). Also activate mixed-language
test cases that would have caught this.
Fixes: #26145
Since commit c26c6ac488 (Link Step: compute effective linker used by the
compiler, 2023-05-27) we use `CMAKE_${lang}_VERBOSE_LINK_FLAG` when
detecting implicit link information. Generate sample test data with it.
As of llvm-project `main` branch commit `86accd4e03` (2023-12-04),
LLVMFlang 18.0.0, when used to drive linking an executable, emits a MSVC
linker flag to use all object files from the `Fortran_main` library.
These object files are meant for use when linking the program entry
point, and so are not implicit link dependencies of Fortran libraries.
These are printed by LLVM-based compiler drivers targeting the MSVC ABI.
In our use case for this, `CMAKE_LINKER` may not yet be known, so do
not include it in the test data.
Update the logic added by commit ef41d49812 (Fix implicit include
directory extraction for adaptive relative paths, 2019-04-08,
v3.14.2~5^2) to account for the new `try_compile` work directory used
for the ABI check since commit 2edf0fc6d7 (Modules: Use new
keyword-dispatched try_compile signature, 2022-09-13,
v3.25.0-rc1~144^2).
Paths relative to the work directory will now have one more `../`
in them, so update the test data to match.
Fixes: #24279
Parse implicit link information for this compiler to support
mixed-language linking. This was missed by commit 85749766df
(LLVMFlang: Add support for LLVM Flang, 2021-07-07, v3.24.0-rc1~86^2).
Also activate mixed-language test cases that would have caught this.
Issue: #22387
The current regular expression is able to match `/usr/lib/<arch>`,
`/usr/usr/lib/<arch>`, `/usr/usr/usr/lib/<arch>`, ... but not
`/lib/<arch>`.
This behavior ends up causing the detected architecture to
be x86_64-pc-linux-gnu when the Clang compiler is installed on
a "non-system" location (like /opt/llvm-13) which, in turn, makes
almost every 'find_library()' fail because the correct
architecture is x86_64-linux-gnu.
This is due to a typo in commit 764606e256 (CMakeDetermineCompilerABI:
Extract lib arch from implicit object file paths, 2021-04-05,
v3.20.1~10^2), which used `+` instead of `?`.
With flags like `-static-libstdc++` or `-static-libgfortran`, the GNU
compiler driver adds `-Bstatic ... -Bdynamic` around its language
runtime library. Convert the libraries in between these to absolute
paths so that mixed-language linking honors the static runtime
libraries.
The NVHPC compiler does not have any implicit link directories that can
be used to detect `CMAKE_LIBRARY_ARCHITECTURE`, but it does have
implicit object files. Extract implicit object file paths from link
lines and check them for the `CMAKE_LIBRARY_ARCHITECTURE` pattern.
Issue: #22024
It is currently presumed that the linker will generate
a space separated line. This is not the case for some
compilers such as IBM XL where it can output space or
comma separated. This is particularly apparent when IBM XL
is used as the host compiler for CUDA as it generates a comma
separated link line.
Brad King