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