Is this a problem with cmake or with my setup?
brad.king at kitware.com
Thu Aug 5 22:12:04 CEST 2010
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
> 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
> 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.
More information about the Kde-buildsystem