KDE and MADDE

Sun Nov 20 13:48:18 UTC 2011

On Sunday 20 November 2011, Aleix Pol wrote:
> On 11/20/2011 12:57 PM, Alexander Neundorf wrote:
> > Hi,
> > 
> > I think the short answer is that there is currently no supported way to
> > mix libraries in such a way when crosscompiling.
> > 
> > There are multiple issues.
> > RPATH, configured directories, and probably all that what our Windows
> > developers also suffer from (where the user can change the install
> > directory at install time).
> > 
> > Currently the best way is probably to do it all in scratchbox
> 
> This is not really a problem. It's CMake insisting on using the full
> library path location.
> And really...? I mean, Qt works just fine, so do other libraries.
> 
> > (or all in cross-compiling, but then with RPATH disabled, development
> > _only_ done via cross compiling, and some other configured paths
> > probably have to be taken care of).
> > 
> > On Sunday 20 November 2011, Aleix Pol wrote:
> >> On 11/19/2011 09:43 PM, Alexander Neundorf wrote:
> >>> On Saturday 19 November 2011, Aleix Pol wrote:
> >>>> 2011/11/19 Alexander Neundorf<neundorf at kde.org>
> >>>> 
> >>>>> On Saturday 19 November 2011, Aleix Pol wrote:
> >>>>>> Hi,
> >>>>>> At the KDE Mobile sprint I have been trying to get madde to compile
> >>>>>> KDE Applications on harmattan using cmake.
> >>>>>> 
> >>>>>> I have got it to work but there are some problems coming from the
> >>>>>> way we find KDE and I'm not sure how to fix them correctly. The
> >>>>>> problem is
> >>>>> 
> >>>>> mainly
> >>>>> 
> >>>>>> the two files that specify where things are installed:
> >>>>>> KDELibsDependencies.cmake and KDELibs4LibraryTargets-debian.cmake.
> >>>>>> Both have the same problem: they are using paths that are relative
> >>>>>> to the system's root and I need them to be relative to the system
> >>>>>> targetted by cmake $ENV{SYSROOT_DIR}.
> >>>>> 
> >>>>> Is the RPATH the problem or where causes it problems exactly ?
> >>>>> 
> >>>>> Alex
> >>>> 
> >>>> No, the problem is hardcoded compile-time locations.
> >>> 
> >>> Yes, and which problem do they cause ?
> >>> 
> >>>> My ugly-hack-workaround is this:
> >>>> http://proli.net/meu/kde/kde_cmake_madde.patch
> >>> 
> >>> I'm downloading QtSDK right now, this contains MADDE, right ?
> >>> 
> >>> Is this running ARM in a virtual machine or does it work differently ?
> >> 
> >> No, it's ARM crosscompilers + the libraries to link to (and packaging
> >> tools and other stuff).
> >> 
> >>> @@ -18,7 +18,7 @@
> >>> 
> >>>    SET_PROPERTY(TARGET KDE4__nepomukquery APPEND PROPERTY
> >>> 
> >>> IMPORTED_CONFIGURATIONS DEBIAN)
> >>> 
> >>>    SET_TARGET_PROPERTIES(KDE4__nepomukquery PROPERTIES
> >>>    
> >>>      IMPORTED_LINK_DEPENDENT_LIBRARIES_DEBIAN
> >>>      "KDE4__kdecore;KDE4__nepomuk"
> >>> 
> >>> -  IMPORTED_LOCATION_DEBIAN "/usr/lib/libnepomukquery.so.4.7.0"
> >>> +  IMPORTED_LOCATION_DEBIAN
> >>> "$ENV{SYSROOT_DIR}/usr/lib/libnepomukquery.so.4.7.0"
> >>> 
> >>>      IMPORTED_SONAME_DEBIAN "libnepomukquery.so.4"
> >>>      )
> > 
> > Now that looking at that again, just earlier this week I committed a
> > patch to cmake so that it checks that the referenced file actually also
> > exists on disk. So with cmake 2.8.7 this would give an error at cmake
> > time:
> > "The imported target KDE4__nepomukquery references the file
> > /usr/lib/libnepomukquery.so.4.7.0, which does not exist".
> > 
> > I was thinking hard about reasons how to get to such an error condition,
> > and could figure out only three ways (manually messing things up,
> > interruping a make install or uninstall, a badly packaged package), and
> > now here we have already another one.
> 
> Well not really, the thing here is that we might want to relocate the
> libraries to different places.
> It doesn't really make sense that if the kde dir is one, but the library
> is somewhere else.
> 
> >>> If IMPORTED_LOCATION_DEBIAN says /usr/lib/libfoo.so, then libfoo.so has
> >>> been installed to that directory.
> >>> How was that done ?
> >>> Is that really /usr/lib in the root filesystem of the host or something
> >>> else ? Was this maybe done in a virtual machine ?
> >> 
> >> Scratchbox, it's a different way to compile against maemo/harmattan
> > 
> > Just to make 100% sure: Scratchbox is a virtual ARM machine, right ?
> 
> Yes, with some tweaks (the compiler is x86 targetting arm, it's not
> emulated, but other things are).
> 
> >> and where it will be installed.
> > 
> > ...and inside this ARM VM libnepomukquery.so.4.7.0 has been built and
> > installed.
> > 
> > How did the library get from the directory /usr/lib in the ARM VM into
> > the directory /home/apol/QtSdk/Madde/sysroots/.../usr/lib ?
> 
> you install it to madde:
> mad-admin xdpkg -i <mylibrary.deb>

Ah, ok.
So this is basically a "natively" on the target system compiled package 
(whether in a VM or really on the ARM doesn't matter), which is now used in a 
cross compilation setting.
And this installation more or less fakes that /home/apol/QtSdk/Madde/sysroots/ 
is the actual root, but cmake is only partly aware of that.

> then it's in the sysroot tree, with all stuff inside together with the
> rest of installed packages.
> 
> > Or is it using the same directory tree ?
> > 
> >> That would be host then.
> >> 
> >>> And why is it needed later on relative to something else ?
> >> 
> >> In madde I have it in: /home/apol/QtSdk/Madde/sysroots/.../usr/lib
> > 
> > What I wondered is why the bin/ directories were empty in the sysroots/.
> > Where are the binaries (independent from the current problem) ?
> > 
> > 
> > So, assuming cmake would figure out that the path
> > /usr/lib/libnepomukquery.so.4.7.0 is inside the target directory tree,
> > and would find it is is now actually
> > /home/apol/QtSdk/Madde/sysroots/.../usr/lib/libnepomukquery.so.4.7.0,
> > that's just the first problem solved.
> 
> yes it's like that. That's why I prepended $ENV{SYSROOT_DIR}/ in my patch.
> 
> > Next is RPATH. Are you building with RPATH, or did you disable RPATH ?
> > With RPATH will be hard.
> > When linking something against
> > /home/apol/QtSdk/Madde/sysroots/.../usr/lib/libnepomukquery.so.4.7.0,
> > cmake will figure out that some executable needs
> > "/home/apol/QtSdk/Madde/sysroots/.../usr/lib/" as RPATH.
> > This would be the correct RPATH from the POV of the (build)host, but
> > completely wrong for the target host.
> 
> We're not using RPATH right now, 

That's good, one problem less.

> it doesn't make that much sense for us
> because we have to ship the libraries in /opt, at least if we want to
> get in stores, because those don't support package dependencies (:D
> yeah, awesome, right?).
> 
> > Then, also in some dbus desktop files path are configured, just last week
> > Ralf Habacker from our Windows team complained that they don't work
> > under Windows because they contain the paths from build time (which
> > would be here /home/apol/QtSdk/Madde/sysroots/.../usr/....) but when
> > trying to run it, this would be wrong obviously.
> 
> We've tested a small amount of applications, we haven't got that far yet.
> 
> > When cross compiling, cmake considers the variable CMAKE_FIND_ROOT_PATH
> > when searching stuff ( see
> > http://www.vtk.org/Wiki/CMake_Cross_Compiling).
> 
> Yes, that's the CMake call I have at kalgebra's debian/rules file.
> 
> cmake $(CURDIR) \
>          -DKDE4_DATA_DIR=${SYSROOT_DIR}/usr/share/kde4/apps/ \
>          -DCMAKE_FIND_ROOT_PATH=${SYSROOT_DIR}/ \
>          -DKDE4_INCLUDE_DIR=${SYSROOT_DIR}/usr/include/ \
>          -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/kalgebra/opt/kalgebra \
>          -DQTMML_LIBRARY=OFF \
>          -DMOBILE_BACKEND="harmattan"
> 
> the 2 last defines are used to adapt the compilation to KAlgebra of course.
> 
> > Now let's say it found a library there (nepomukquery).
> > When linking against this, it would have to tell the linker to link with
> > the host path, but use the target path for the RPATH, i.e. remove the
> > directory which was used from CMAKE_FIND_ROOT_PATH when calculating the
> > RPATH.
> > 
> > Something similar would have to be done when creating the file with the
> > exported targets (this file is created by cmake, we cannot change it).
> > Currently it will write the full current location in the target
> > properties, i.e. it would be
> > /home/apol/QtSdk/Madde/sysroots/.../usr/lib/libnepomukquery.so.4.7.0.
> > This would be correct when used from the build host, but now when used
> > from the target host (or VM).
> 
> I don't think RPATH will ever work in our setup. Right now we're just
> adding an LD_LIBRARY_PATH in a shell file to load the application, dirty
> but the only way we've found out.
> 
> > Handling all that properly in cmake is not trivial, and needs a good
> > plan. So, I'm afraid nothing to do quickly.
> > 
> > 
> > You have a cmake toolchain file set up for cross compiling, right ?
> > Can you please post this here ?
> 
> I don't have any, no.

This means you don't preset CMAKE_SYSTEM_NAME, this means cmake assumes it is 
compiling natively, and not cross compiling.
This means if there are configure checks which do try_run() internally, they 
will not work. It also means it doesn't differentiate between (build) host and 
target, and make wrong assumptions in places.

So, you are crosscompiling, you really should preset CMAKE_SYSTEM_NAME.

How does it actually find the compiler ?
I would have expected you have to preset this too.

Alex