Re: Bits from ARM porters
On Tue, Dec 03, 2013 at 12:30:16PM +0100, Hector Oron wrote:
> 2013/12/3 Lisandro Damián Nicanor Pérez <perezmeyer@gmail.com>:
> > Hector Oron wrote:
> > [snip]
> >> 5.1 Enable buildd support
> >> ─────────────────────────
> >>
> >> ⁃ Fast model system (initial bootstrapping only)
> >> ⁃ QEMU support (bootstrapping to the point of a buildd image &
> >> recompile it all again)
> >> ⁃ Real hardware accessible to Debian (?)
> >> ⁃ Qt issues make it hard with emulators. May build, might not work.
>
> > Would this be a Qt problem related to the emulator or the the toolkit
> > itself?
> >
> > /me with his Qt maintainer hat on (which might be too big, but oh well...)
>
> That was a comment done by Canonical folks, iirc Adam Conrad, talking
> from their experience on emulated builds. Maybe, they are able to
> expand on the comment.
It's not a problem with Qt as such. The problem is that qemu-user tends
to get very upset when multithreading is involved, and Qt likes to use
threads. We escalated it to the emulator folks in Linaro some time ago,
but I'm told that fixing this in qemu is a very substantial project
which nobody's currently working on.
https://bugs.launchpad.net/qemu/+bug/1084148
The approach used by Launchpad's ARM PPA builders where you install
qemu-user-static and emulate foreign-architecture binaries on the fly is
a neat trick, and works for a subset of packages. But until qemu-user
is made a *lot* more robust, it doesn't stand a chance of being able to
build the whole archive; and Qt is low enough down the dependency chain
that in practice you run into this sooner than you might expect or want.
qemu-system doesn't suffer from this class of problems. On the other
hand it's significantly slower, and you may have some amusement getting
it to do such things as emulating a machine with sufficient memory and
I/O.
--
Colin Watson [cjwatson@debian.org]
Reply to: