bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#76177: _LT_SYS_HIDDEN_LIBDEPS oddities with Fortran


From: Christian Feld
Subject: bug#76177: _LT_SYS_HIDDEN_LIBDEPS oddities with Fortran
Date: Mon, 10 Feb 2025 19:28:45 +0100
User-agent: Mozilla Thunderbird

I tried again with the latest libtool release. With that version, I don't see the '... -l -l ...' and '... -L -L ...'. Good!

The observation that postedeps_FC is empty in the absence of AC_PROG_CXX still holds, though.

Christian


On 10.02.25 11:53, Christian Feld wrote:
Dear libtoolers,

my project uses C, C++, Fortran 77. One library consists of mixed CC and F77 sources. I intend to switch to more modern Fortran (FC) for this library.

Linking this library with F77LINK worked well. Switching to FCLINK causes errors for some compilers due to broken postedeps_FC.

  - For HPE Cray PrgEnv-cray's ftn, postedeps_FC contains '... -L -L ...'.
 - For HPE Cray PrgEnv-gnu's ftn, OpenMPI's and MPICH's mpifort (delegating to gfortran), postedeps_FC contains '... -l -l ...'.

During investigating the cause of the broken postdeps_FC, several questions arose.

1. Why do we have postdeps for CXX and FC, but not for CC and F77? _LT_SYS_HIDDEN_LIBDEPS is expanded in _LT_LANG_CXX_CONFIG and _LT_LANG_FC_CONFIG only.

2. Why do we need postdeps at all? Isn't the compiler supposed to do just the right thing?

3. Without a C++ compiler (AC_PROG_CXX), postedeps_FC is always empty, as output_verbose_link_cmd, the command producing the input to determine the postdeps, is set in _LT_LANG_CXX_CONFIG only. If this is coupling intended, can you please explain why?


Now, where do the bogus `... -L -L ...` and `... -l -l ...` come from? The output_verbose_link_cmd used for CXX and FC postdeps is     '$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP -v "^Configured with:" | $GREP " [[-]]L"' For the compilers mentioned above, the output of this command contains a line starting with 'Driving:', e.g.,

Driving: /p/software/jedi/stages/2025/software/GCCcore/13.3.0/bin/ gfortran -shared -g -O2 -v conftest.o -I/p/software/default/stages/2025/ software/OpenMPI/5.0.5-GCC-13.3.0/include -I/p/software/default/ stages/2025/software/OpenMPI/5.0.5-GCC-13.3.0/lib -L/p/software/default/ stages/2025/software/OpenMPI/5.0.5-GCC-13.3.0/lib -Wl,-rpath -Wl,/p/ software/default/stages/2025/software/OpenMPI/5.0.5-GCC-13.3.0/lib - Wl,--enable-new-dtags -lmpi_usempif08 -lmpi_usempi_ignore_tkr - lmpi_mpifh -lmpi -l gfortran -l m -shared-libgcc

The part '-l gfortran -l m' results in '... -l -l ...'


Lines starting with 'Configured with:' are already omitted in output_verbose_link_cmd. Omitting lines starting with 'Driving:'  as well would fix the invalid postdeps_FC. Note that autoconf's _AC_PROG_FC_V_OUTPUT also omits both, '^Driving:' and '^Configured with:', see [1].

A patch omitting lines '^Driving:'  is attached. But do we need to expand _LT_SYS_HIDDEN_LIBDEPS for FC at all?

Thanks,
Christian

[1] https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/ autoconf/ fortran.m4;h=cdc197bd67f4abab036cfe6a3a59d16aa712a386;hb=6199cff2909e0ac84c9391aa49ed097d6a33268d#l514

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]