On Wednesday 04 August 2010, Brad King wrote: > 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
Wouldn't this mean to parse the ELF header, find all required shared libs, and look for them too ? Also, I think you can't reliable figure out at build time which shared lib will be used at runtime. LD_LIBRARY_PATH may be set, /etc/ld.so.conf may be different, it could be executed on a different system, etc. > 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 Hmm, wouldn't we still have a problem ? Qt has been built with phonon, and some parts of Qt most probably link against this phonon in qt/lib/. khtml has been linked against phonon in kdesupport/lib/, and we'd like to use that one, since it is newer. But, if cmake would have the full information, i.e. that Qt would like to have the one in qt/lib/, and that khtml the one in kdesupport/lib/, wouldn't we get a conflict then ? Is maybe the whole situation just a mess with phonon being built as part of Qt and also independent from it ? Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
