KDE and MADDE

Sun Nov 20 12:37:00 UTC 2011

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>

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, 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.
>
> So, this email is not really like "this is a solution", it's more a collection
> of issues which need to be handled.
>
> Alex
Agree, it would be really nice to solve this issues eventually, if we 
want to reach the mobile and embedded world.
Thanks for the thorough answers, I'm hoping we'll find a solution soon :).

Aleix