Is this a problem with cmake or with my setup?

[Brad King]

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