On 08/05/2010 03:41 PM, Alexander Neundorf wrote: > On Wednesday 04 August 2010, Brad King wrote: >> 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?
Perhaps, but at the point we do this we would have no more information than the linker would when it finds the library in the -rpath-link path. I think we would just have to stop here and "hope it works". There is only so much we can do without the full dependency chain as imported targets. > 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. True; I worded that poorly. We actually want to find the soname library file or symlink that the linker will load when creating the target. This is still a build-time thing. The path to the soname-ed file needs to be used in the analysis I described. >> 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. Yes. At runtime the dynamic linker may not be able to satisfy both Qt and khtml. > 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 ? Yes. It would generate a warning that no safe rpath-link search path can be computed. > Is maybe the whole situation just a mess with phonon being built as part of > Qt > and also independent from it ? The problem is that there are two libphoton.so libraries with the same soname but that are not interface-compatible. If they had different soname values then the two separate libraries might be able to load into the same process. -Brad _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem