On 08/03/2010 06:45 PM, Michael Jansen wrote: > 1. Where does that list after rpath-link come from?
CMake computes it based on the known shared library implementation dependencies. For targets built in the tree these come from their full list of libraries used for linking (not the link interface). For imported targets these come from a target property called IMPORTED_LINK_DEPENDENT_LIBRARIES The property should be set when the imported target is created. CMake's install(EXPORT) command copies the shared library dependency information into the above property when exporting a shared library target. >From the above CMake constructs a list of full paths to the library files (sonames) that it knows must be found at link time. It then inspects the directories containing these libraries for conflicts, constructs a constraint graph, and generates a safe order for the directories to be listed with the -rpath-link flag. > 2. How can i influence it's content? There is no direct interface for it. One must give CMake enough information for the above automatic algorithm to work. If all the libraries involved in linking every CMake-built shared library along the way were brought in as imported targets then it would work. However, this is not the case for the Qt libraries AFAIK. For a shared library target CMake distinguishes its link interface dependencies (or "link interface") from its link implementation dependencies (or "link implementation"). It computes the set of shared libraries that go in IMPORTED_LINK_DEPENDENT_LIBRARIES by identifying shared libraries in the target's link implementation but excluding those in the target's link interface. The result is the set of "dependent libraries". In the default case the link interface is the same as the link implementation so the list of dependent libraries is empty. When LINK_INTERFACE_LIBRARIES is set (which happens in your case) then the list can be non-empty. However, it will only every consist of the libraries from the link implementation that CMake *knows* are shared libraries. Currently the definition of "knows" is that the dependent library is a *target* (imported or built) and not just a file name. One can see the code in CMake 2.8.2 in the file Source/cmTarget.cxx at lines 4222-4245: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;h=45ba3584;hb=v2.8.2#l4207 Note the TODO comment. It does not recognize shared libraries by file name. This causes your problem because the file /path/to/kde4/trunk/support/libphoton.so does not end up in the list of known dependent libraries. Therefore it is not included in the above-mentioned ordering algorithm and /path/to/kde4/trunk/support does not end up in the -rpath-link option. Unfortunately implementing the TODO comment is non-trivial. CMake must first recognize shared library full-path file names from the link implementation list. Then for each shared library it finds it must also locate the full path to the file that will be loaded at runtime based on the *soname* of the library! In simple cases the soname is the same as the library, or the library file is just a symlink to the soname, but in the worst-case we need to know and understand the library's ABI to parse out the soname. > 3. Do we have a problem with our LINK_INTERFACE by only being > able to specify which libs we need and not being able to > specify where WE took it from? KHTML needs phonon but it does > not tell me openly. The KHTML imported target *should* come with libphoton.so listed in the IMPORTED_LINK_DEPENDENT_LIBRARIES property. It does not right now because - libphoton.so was not imported as a target when khtml was built - CMake did not recognize it as a runtime dependency of khtml due to the lack of implementation at the above-mentioned TODO > So how am i supposed to make sure it's found? As a hack, you might be able to add your own -Wl,-rpath-link option to the CMake cache in the entries CMAKE_EXE_LINKER_FLAGS (to help executables link) CMAKE_SHARED_LINKER_FLAGS (to help shlibs link) The linker may take both instances of -rpath-link and combine the paths. -Brad _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
