Is this a problem with cmake or with my setup?

[Michael Jansen]

On Wednesday 04 August 2010 00:45:01 Michael Jansen wrote:
> Hi
> 
> In the last days/week i get more and more linking problems. I have them
> mostly with phonon. In my journey to better understand all that linking
> stuff i kept searching for the reason. Here is what i found so far:
> 
> The problem itself is easy. Qt ships a phonon without the symbol
> Phonon::VideoPlayer::Event(QEvent*). This was added in phon git recently.
> As we still haven't found a satisfying solution for the problem how to
> build qt with respect to phonon if you want qt's phonon support AND phonon
> from git i pretended there is no problem and compiled both qt with phonon
> and phonon itself.
> 
> Qt goes into /kde4/qt/4.6 (But it's 4.7 git/master)
> Phonon goes into /kde4/trunk/support
> 
> Given the promise of rpath and our advanced build system i hoped things
> would work. But they do not. From time to time stuff suddenly fails to
> link. The reason is simple.
> 
> As an example currently kdepim is falling for me.
> 
> cd /home/mjansen/kde4/trunk/bld/KDE/kdepim/akregator/export &&
> /usr/bin/cmake -E cmake_link_script
> CMakeFiles/akregatorstorageexporter.dir/link.txt --verbose=1
> /kde4/trunk/kde/bin/c++    -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef
> -Wcast-align -Wchar- subscripts -Wall -W -Wpointer-arith -Wformat-security
> -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check- new -fno-common
> -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden
> -fvisibility- inlines-hidden -g -O2 -fno-reorder-blocks
> -fno-schedule-insns -fno-inline  -Wl,--enable-new-dtags -
> Wl,--no-add-needed -Wl,--fatal-warnings
> CMakeFiles/akregatorstorageexporter.dir/akregatorstorageexporter_automoc.o
> CMakeFiles/akregatorstorageexporter.dir/akregatorstorageexporter.o  -o
> akregatorstorageexporter - rdynamic -L/kde4/trunk/kde/lib64
> -L/home/mjansen/kde4/trunk/bld/KDE/kdepim/lib -L/kde4/qt/4.6/lib64
> /kde4/trunk/kde/lib64/libkdecore.so.5.6.0
> /kde4/trunk/kde/lib64/libsyndication.so.4.6.0
> ../../lib/libakregatorinterfaces.so.4.6.0
> /kde4/trunk/kde/lib64/libsyndication.so.4.6.0
> /kde4/trunk/kde/lib64/libkdecore.so.5.6.0 /kde4/qt/4.6/lib64/libQtDBus.so
> /kde4/qt/4.6/lib64/libQtCore.so -lpthread -Wl,-
> rpath,/home/mjansen/kde4/trunk/bld/KDE/kdepim/lib:/kde4/trunk/kde/lib64:/kd
> e4/qt/4.6/lib64 -Wl,-
> rpath-link,/home/mjansen/kde4/trunk/bld/KDE/kdepim/lib:/kde4/trunk/kde/lib
> 64 /kde4/trunk/kde/lib64/libkhtml.so.5: undefined reference to
> `Phonon::VideoPlayer::event(QEvent*)' collect2: ld returned 1 exit status
> make[2]: *** [akregator/export/akregatorstorageexporter] Fehler 1
> make[2]: Leaving directory `/home/mjansen/kde4/trunk/bld/KDE/kdepim'
> make[1]: *** [akregator/export/CMakeFiles/akregatorstorageexporter.dir/all]
> Fehler 2 make[1]: Leaving directory
> `/home/mjansen/kde4/trunk/bld/KDE/kdepim' make: *** [all] Fehler 2
> 
> As you can see it complains that it can't resolve a symbol for khtml. Which
> is not specified on the commandline. It picks that up as a dependency for
> some other shared lib. It then picks up a libphonon itself too. The
> directories it looks into for those libs are those specified by the linker
> command line option
> -rpath-link,/home/mjansen/kde4/trunk/bld/KDE/kdepim/lib:/kde4/trunk/kde/li
> b64

As usual i forgot something. If it can't find the lib in -rpath-link it looks into the directories 
specified with ,-
-rpath,/home/mjansen/kde4/trunk/bld/KDE/kdepim/lib:/kde4/trunk/kde/lib64:/kde4/qt/4.6/lib64

As we can see there is qt in there but no support. That's why it pick up phonon from qt instead of 
phonon from kdesupport.

> Seeing that its easy to understand why the libphonon from
> /kde4/trunk/support is not picked up. It's not part of that list. If i add
> it everything works fine.
> 
> The list there has absolute precedence so i have no way to make it link but
> adding phonon to khtml's link interface. Which it is not part of because
> khtml does not expose it in it's api.
> 
> If i remove the libs from the qt installtion directory everything links.
> But if i understand the man page correctly this is only because i have a
> native linker. It picks phonon either over LD_LIBRARY_PATH or the
> DT_NEEDED and RPATH flags from some already known shared lib.
> 
> When cross-compiling things should fail completely. Because there is no
> rule after rpath that would pick up a correct version
> 
> I had the same problem with a poppler distro package. During some linking
> it would pick up indirectly the poppler lib from /usr/... instead of my
> self compiled version. Remember we only speak of the linking. Running
> picks up the correct lib because of LD_LIBRARY_PATH
> 
> So my questions:
> 
> 1. Where does that list after rpath-link come from?
> 2. How can i influence it's content?
> 3. Do we have a problem with our LINK_INTERFACE by only beeing able to
> specify which libs we need and not beeing able to specify where WE took it
> from? KHTML needs phonon but it does not tell me openly. So how am i
> supposed to make sure it's found?
> 
> Or do i really have to remove all distro-package for each and every self
> compiled part of my kde development setup. And i mean the libs not some
> devel-packages.
> 
> Mike
> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem