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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
