Re: [meta-qt5] Problems with Qt5 and CMake

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3679 bytes --]

On Fri, May 24, 2013 at 01:34:40PM +0200, Manuel Nickschas wrote:
> Hi,
> 
> we're trying to deploy a Qt5-based piece of software on a Yocto system (I 
> hope this is on topic for this mailing list as well; the issue I'm about to 
> describe should occur on pure OE too). As build system for this software, we 
> use CMake.
> 
> We've added meta-qt5 (master) and successfully installed qtbase on the 
> platform. However, there is a serious issue if one tries to cross-compile 
> CMake-based software against the resulting Qt5 installation.
> 
> As you probably know, Qt5 ships its own support for CMake in the form of a 
> bunch of Qt5$ModuleConfig.cmake files somewhere in /usr/lib/cmake. 
> These files are found with a find_package(Qt5Core) call and set everything 
> needed for building against the Qt5 installation. The problem is, that those 
> files contain absolute paths to both the libraries and the host tools for 
> building (such as moc, rcc etc).
> 
> meta-qt5 actually installs two sets of CMake files for Qt5, one in the target 
> sysroot (from the qtbase package) and one in the native sysroot (from the 
> qtbase-native package). A recipe inheriting cmake.bbclass will find the ones 
> in the target sysroot.
> 
> The issue is that these files hardcode the paths *on the target*, i.e. they try 
> to find the host tools in /usr/bin/qt5/ and the libraries in /usr/lib/. Obviously, 
> this fails when trying to build against those, because the target sysroot path 
> isn't prepended.
> 
> If I remove the CMake files from the target sysroot (could not figure out how 
> to force it otherwise in my recipe), the ones from the native sysroot are found 
> and used instead. These actually contain proper paths into the native 
> sysroot, so the build tools - like moc - are found and the program compiles 
> successfully - but it can't link, because it then tries to link to the libraries in 
> the native sysroot. And those are, of course, built for the wrong architecture.
> 
> I'm at a loss as of how to properly fix this issue. What we need is a set of 
> CMake config files for Qt5 that point to the tools in the native sysroot and the 
> libraries in the target sysroot. However, we probably wouldn't want to deploy 
> them as such on the target (because there we want to actually point to both 
> tools and libraries in /usr for the target), and we probably also wouldn't want 
> to do it in the native sysroot (because then we couldn't build native things 
> that like to link to the native libraries).
> 
> Of course, I could just copy the CMake files from Qt5, patch them 
> accordingly and ship them as part of my project; but bundling such things is 
> evil and I would really like to avoid this.
> 
> So now I'm wondering, are people here aware of that issue and have a plan 
> or idea on how to fix this?
> 
> https://bugreports.qt-project.org/browse/QTBUG-28922 might be relevant, 
> although I am not sure if this is describing a similar issue and if it applies to 
> the multiple sysroot approach Yocto uses.
> 
> Thank you for any pointers.

I don't have any component which uses CMake and Qt5, so I haven't tested
this, but .prl, .la and .pc files were also generated with wrong paths,
check those patches in qtbase.

It would be good to let CMake respect OE_QMAKE_PATH_* variables, so you can
generate .cmake files with correct paths for target and in OE builds
override them with OE_QMAKE_PATH_* values to use correct sysroot.

The same for finding native host tools in
OE_QMAKE_PATH_EXTERNAL_HOST_BINS

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]