By running "readelf -d <executable name>" I have recently become aware that the Debian Buster linker automatically turns all rpath requests into runpath, and that runpath versus rpath difference apparently creates some issues I am trying to debug for the PLplot OCaml binding that did not appear for my previous (Debian Jessie) platform. (Note, that our ocaml binding implements its language support in a primitive way using add_custom_command and add_custom_target because as far as I know there is no OCaml language support in upstream CMake.) These runpath issues only show up for the PLplot build-tree configuration that links all PLplot components statically, but note that external libraries (such as libLASi, see below) are still linked as shared for this case.
CMake does the right thing in the build tree for the corresponding C example (with obviously good CMake language support for C) so I need some help in figuring out what goes on there so that I can also do the right thing for OCaml. (Note for the PLplot static build, the PLplot libraries and C executables are all built using the PUBLIC signature of target_link_libraries to force transitive linking in this (static) case.) The reason I have to be concerned about runpath is one of those external libraries (libLASi) is locally built and installed in a non-standard location so we have this situation for it: software@merlin> readelf -d /home/software/lasi_svn/install/lib/libLASi.so |grep -Ei 'needed|path' 0x0000000000000001 (NEEDED) Shared library: [libpangoft2-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libfontconfig.so.1] 0x0000000000000001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libfreetype.so.6] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000001d (RUNPATH) Library runpath: [/home/software/lasi_svn/install/lib] In a PLplot C example, the result of a build that was completely automated by CMake (with no mention of rpath in our build system for this PLplot static library case) is as follows: software@merlin> readelf -d examples/c/x01c |grep -Ei 'needed|path' 0x0000000000000001 (NEEDED) Shared library: [libLASi.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpangoft2-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libfontconfig.so.1] 0x0000000000000001 (NEEDED) Shared library: [libfreetype.so.6] 0x0000000000000001 (NEEDED) Shared library: [libshp.so.2] 0x0000000000000001 (NEEDED) Shared library: [libqhull.so.7] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000001d (RUNPATH) Library runpath: [/home/software/lasi_svn/install/lib] And the reason for that RUNPATH line was the combination of CMake building this example using the option -Wl,-rpath,/home/software/lasi_svn/install/lib and Debian Testing transmuting that rpath request to runpath. So all is well with that C example, but I would like to know *how* CMake knew (for the build tree case) that the rpath option was needed. That information is not available for any of the PLplot static libraries in this case, and I also cannot find any mention of rpath in our build system logic for this static case. So assuming I haven't missed something in the PLplot build system, I am pretty sure that CMake automatically detected that libLASi itself had RUNPATH set, but if that is true, how did it detect that? For example, does CMake use something like "readelf -d <library name> |grep -i path" for all dependent shared libraries to figure this out, or is there an easier way? Once I get that information, then I will attempt to do something similar for the corresponding OCaml example(s) where the current readelf result is software@merlin> readelf -d examples/ocaml/x01ocaml |grep -Ei 'needed|path' 0x0000000000000001 (NEEDED) Shared library: [libLASi.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpangoft2-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libfontconfig.so.1] 0x0000000000000001 (NEEDED) Shared library: [libfreetype.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libshp.so.2] 0x0000000000000001 (NEEDED) Shared library: [libqhull.so.7] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [libQt5Core.so.5] 0x0000000000000001 (NEEDED) Shared library: [libQt5Gui.so.5] 0x0000000000000001 (NEEDED) Shared library: [libQt5PrintSupport.so.5] 0x0000000000000001 (NEEDED) Shared library: [libQt5Widgets.so.5] 0x0000000000000001 (NEEDED) Shared library: [libQt5Svg.so.5] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] Note that those extra Qt libraries should not be there since this particular test was without the Qt components of PLplot so that is an overlinking issue for our OCaml support I need to address. But the fundamental OCaml issue is RUNPATH is missing, and I hope to address that issue once I know more about how CMake (apparently if my above analysis of the PLplot build system is correct) automatically knows in the build tree when to use the appropriate rpath option for the C language case. 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.sf.net); 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
