The intended solution to this problem is to use the -t capability of sb2 init.
See Fig 5 in the pdf linked below.
Currently -t uses whatever is in the host. That's technically wrong but works
most of the time but as you say, hits problems when the host and target differ
radically. (FWIW it hurt us recently when the 'file' command was changed!)
Essentially you should build an x86 version of the target and then use it to
accelerate the arm build.
There are downsides to this in that all non-x86 targets require an additional
tools rootfs and that for any changes in eg, qmake would require a rebuild (and
reinstall depending on how this is managed) of the tools rootfs before they were
effective in the non-x86 build.
Not only that - if I were to 'zypper in/up' a tool into the arm rootfs then it
would be nice to have that reflected in the x86 rootfs too. In the OBS I would
consider a 1:1 mapping quite(!) important.
Even if we did this then a build of qmake would require the tools rootfs to not
only have all the tools provided by the BuildRequires - but also the tools that
should be generated during the build process.
I would be interested in finding a clean and generic way to do this - the Qt
solution is great and certainly reduces the pressure but it's not trivial.
Also note that the whole point of an accelerated toolchain is to reduce the
build time. If it takes longer to install the native-toolchain than the time
saved using it (highly likely on most transient/OBS builds!) then it really adds
no value.
Musing here: for the OBS it may be feasible to have certain packages identified
as if this appears in the BR for the target then add the x86 variant to the
rootfs using (and depending) on this parallel x86 repository
David
https://raw.github.com/mer-packages/scratchbox2/master/scratchbox2/docs/SB2_internals_1st_ed_20120425.pdf
On 21/02/14 04:02, Chris Chris wrote:
When crosscompiling packages with newer version of the accelerated tools that
are version sensitive such as the qt build tools and cmake you need to ensure
that OBS can find and install matching i486 versions of those tools.
Have a look at mer:devel:qt to see how this is done
1) The sb2-tools-qt5-armv7l-inject and sb2-tools-qt5-armv7hl-inject provide
version specific packages for sb2
2) the meta conf ensures these are built and available to arm
a) arm repo definitions includes the i486 repo
b) the i486 lists the arm schedulers
c) with build disabled
3) the project conf contains a SB2Install and Requires directive for these
packages
The result is that when building with this qt project the inject package is
preinstalled and the build then uses the correct qt build tools for the
version
of qt.
I have used the same approach with projects using newer versions of cmake
To: mer-general@lists.merproject.org
Date: Thu, 20 Feb 2014 17:37:47 +0100
From: davide.bet...@ispirata.com
Subject: [mer-general] don't accelerate qmake/moc/uic while crosscompiling
Hello,
I think we should stop trying to accelerate some binaries like qmake,
moc and uic while crosscompiling, this might be harmful if arm version
of Qt doesn't match accelerated version. For example moc in Qt 5.1
doesn't provide some options required for Qt 5.2 modules.
Bye,
Davide Bettio.
--
Don't worry, you'll be fine; I saw it work in a cartoon once...
