Re: [cmake-developers] For a certain use case, CMake configures linking to the *same* library in both -L... -l... form and raw file form
I have now written [a bug report](https://gitlab.kitware.com/cmake/cmake/issues/19630) that describes this issue. 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
Re: [cmake-developers] For a certain use case, CMake configures linking to the *same* library in both -L... -l... form and raw file form
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 $) 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 $ $) 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
[cmake-developers] For a certain use case, CMake configures linking to the *same* library in both -L... -l... form and raw file form
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 $) 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. My guess is this is actually an expected (albeit peculiar) result for the above use case due to the existing general design of CMake language support, but I thought I had better mention this result here in case it is due to a bug in that support. 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