ubuntu-phone team mailing list archive

[Scott Kitterman <ubuntu@xxxxxxxxxxxxx>]

Dmitrijs Ledkovs <dmitrij.ledkov@xxxxxxxxxx> wrote:
>So at the moment I have hacked up a way to cross compile qml extensions
>[1]
>The solution is not as fluid and packaging changes are needed in qt*
>packages to make all of this nicer.
>
>Foremost one cannot install ubuntu-sdk for multiple architectures:
>$ apt-get install ubuntu-sdk ubuntu-sdk:armhf
>
>Even a more simple case of:
>$ apt-get install qtbase5-dev qtbase5-dev:armhf
>
>Doesn't install because of GL somewhere down the stack:
>qtbase5-dev : Depends: libgl1-mesa-dev but it is not going to be
>installed or
>                        libgl-dev
>       Depends: libglu1-mesa-dev but it is not going to be installed or
>                        libglu-dev
>E: Unable to correct problems, you have h
>
>If you want to experiment with above, enabling armhf is easy:
>$ dpkg --add-architecture
>Add:
>deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports saucy main
>restricted universe multiverse
>
>To sources.list (if you want to get rid of warnings, other
>repositories should list which architectures you want from them, e.g.
>[arch=amd64,i386] for nomal ubuntu mirrors)
>
>Therefore at the moment, I create a chroot where I have most of
>-dev:armhf packages & cross-toolchain installed, whilst on the host
>system is where I install qmake & generate the makefiles.
>
>I've hacked up qmake mkspec files which to honour dpkg-architecture
>fields which is the standard way to declare native or cross
>compilations on Ubuntu. the variables from dpkg-architecutre can be
>exported in the environment, or one can use it as a wrapper script:
>dpkg-architecture -aarmhf -c qmake [2]
>dpkg-architecture -aarmhf -c make clean [3]
>
>Next the qmake mkspecs are all stored in /usr/share/qt5 which is also
>odd, because they are not identical between architectures, thus
>ideally all of them should be moved to
>/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/mkspec
>
>Hence at the moment, I have to use sed on the generated Makefiles to
>replace -lGL with -lGLESv2.
>
>But overall one does able to cross compile qml extensions, even using
>qmake. But the co-installability of ubuntu-sdk for multiple
>architectures must be resolved, otherwise we will be stuck with using
>chroots and jumping between host & chroot to complete a single:
>configure-clean-build cycle. [4]
>
>I have started on changing packaging for qtbase-opensource-src but it
>seems like it's a rather big task which hopefully SDK team can take
>over [5] thus at the moment I'm still monkey-patching in-place system
>level directories.
>
>There is README in the [1] branch outlining how I have cross-compile
>the stock qmlextension template example generated by the ubuntu-sdk.
>And I'm happy to assist & answer any questions about multiarch &
>co-installability requirements here. So far I have filed a couple of
>bugs which must be resolved to allow cross-compilation for the
>ubuntu-sdk [6] There are a few more, e.g. i couldn't install a few
>optional qdeclarative plugins due to non-multiarch reverse
>dependencies.
>
>[1] lp:~ubuntu-core-dev/+junk/qmake-cross
>[2] -a means cross-compile from by build architecute to that target
>host architecture, e.g. armhf in this case.
>[3] if the generated makefiles have "include
>/usr/share/dpkg/architecture.mk" then there will be no need to wrap
>calls to make.
>[4] well since replacing ones host system GL with something else does
>usually break stuff
>[5] lp:~xnox/kubuntu-packaging/qtbase-opensource-src
>[6] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qmake-cross

Changes like this should really be coordinated in Debian so we don't accumulate long term differences that can't easily be resolved. 

Why do you need to cross compile QML anyway? It's not like you need it for bootstrapping. 

Scott K