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<[email protected]>
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
_______________________________________________
Kde-buildsystem mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-buildsystem
