KDE and MADDE

Sun Nov 20 11:57:31 UTC 2011

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

(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.

> > 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 ?

> 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 ?

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.

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.

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.

When cross compiling, cmake considers the variable CMAKE_FIND_ROOT_PATH when 
searching stuff ( see http://www.vtk.org/Wiki/CMake_Cross_Compiling).

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).

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 ?

So, this email is not really like "this is a solution", it's more a collection 
of issues which need to be handled.

Alex