[cmake-developers] For a certain use case, CMake configures linking to the *same* library in both -L... -l... form and raw file form

[Alan W. Irwin]

On 2019-08-17 13:00-0700 Alan W. Irwin wrote:

> To temporarily work around some bugs in cmake-d support for the D
> language case, I modified our normal use case for PLplot linking
> between our D examples and D binding.  And that lead to the peculiar
> result mentioned on the subject line which I have now also confirmed
> for the Fortran language.  (So I presume this result holds both for
> externally supported languages such as D and languages officially
> supported by CMake such as Fortran.)
>
> The PLplot Fortran examples link to the PLplot Fortran binding library
> whose target name is PLPLOT::plplotfortran.  And PLplot uses
> non-transitive linking on my (Linux, Debian Buster) platform.
>
> So in the shared library build case, if I link the Fortran examples
> using my normal method:
>
> target_link_libraries(x${STRING_INDEX}f PLPLOT::plfortrandemolib 
> PLPLOT::plplotfortran)
>
> the resulting link command for our x00f example (and similarly for all
> the rest) is
>
> [100%] Linking Fortran executable x00f
> cd /home/software/plplot/HEAD/build_dir/examples/fortran && 
> /home/software/cmake/install-3.13.2/bin/cmake -E cmake_link_script 
> CMakeFiles/x00f.dir/link.txt --verbose=1
> /usr/bin/gfortran   -O3 -Wuninitialized -Wunused 
> CMakeFiles/x00f.dir/x00f.f90.o  -o x00f 
> -Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/fortran 
> ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0 
> make[3]: Leaving directory '/home/software/plplot/HEAD/build_dir'
> [100%] Built target x00f
>
> which is the expected result (which mentions the link to the
> plplotfortran library only in raw file format).  (N.B. I set the
> environment variable FFLAGS="-O3 -Wuninitialized -Wunused" which
> explains those special gfortran options.)
>
> However, if I link the Fortran examples with
>
> target_link_libraries(x${STRING_INDEX}f PLPLOT::plfortrandemolib 
> $<TARGET_LINKER_FILE:PLPLOT::plplotfortran>)
> add_dependencies(x${STRING_INDEX}f PLPLOT::plplotfortran)
>
> the resulting link command for our x00f example (and similarly for all
> the rest) is
>
> [100%] Linking Fortran executable x00f
> cd /home/software/plplot/HEAD/build_dir/examples/fortran && 
> /home/software/cmake/install-3.13.2/bin/cmake -E cmake_link_script 
> CMakeFiles/x00f.dir/link.txt --verbose=1
> /usr/bin/gfortran   -O3 -Wuninitialized -Wunused 
> CMakeFiles/x00f.dir/x00f.f90.o  -o x00f 
> -L/home/software/plplot/HEAD/build_dir/bindings/fortran 
> -Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/fortran 
> ../libplfortrandemolib.a -lplplotfortran 
> ../../bindings/fortran/libplplotfortran.so.0.2.0 make[3]: Leaving directory 
> '/home/software/plplot/HEAD/build_dir'
> [100%] Built target x00f
>
> I expected that the result would simply link to the plplotfortran
> library in "-L/home/software/plplot/HEAD/build_dir/bindings/fortran
> -lplplotfortran" form so that redundant mention of the *same* library
> in raw file form (../../bindings/fortran/libplplotfortran.so.0.2.0)
> was a surprise to me.

Hi Ben:

Thanks for contacting me off list concerning this issue.

I have now done some more experiments and it appears the issue does
not exist unless the following specific conditions are met:

1. There must be at least two library items (i.e., the target links to
at least two libraries) mentioned in the target_link_libraries
command.  For example, I was unable to replicate the issue with our C
and C++ examples (where only one library item is mentioned in the
target_link_libraries command), and similarly if I (incorrectly)
dropped plfortrandemolib from the items mentioned for the
target_link_libraries command for our Fortran examples the issue
disappeared (although that incomplete linking generated other issues,
as expected).

2. The two item libraries must be built in different ways.  For
example, plfortrandemolib is normally built as a static library and
plplotfortran is built as a shared library, but the issue disappeared
if both libraries were built as shared libraries.

3. The example must link to the two item libraries in two different
ways.  For example, the issue disappeared if I used

target_link_libraries(x${STRING_INDEX}f $<TARGET_LINKER_FILE:PLPLOT::plfortrandemolib> $<TARGET_LINKER_FILE:PLPLOT::plplotfortran>)
add_dependencies(x${STRING_INDEX}f PLPLOT::plfortrandemolib PLPLOT::plplotfortran)

where as a result of that logic, the Fortran examples link to both
plfortrandemolib and plplotfortran using the same -L... -l... link
method.

It does appear this issue is independent of language.  For example, I
can replicate it for our D examples where the above 3 conditions were
met, but that issue disappeared if, for example, I link the D examples
to both of the two item libraries using the -L... -l... link method.

I would appreciate it if you took a quick look to see if there is an
easy fix for this extremely specific issue, and if not then I would be
willing to put it on the bug tracker to reduce the chances it will get
lost.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________