Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Hans-Christian Egtvedt <hcegtvedt@atmel.com>
To: buildroot@busybox.net
Subject: [Buildroot] Qtopia4 fails building - target stage tries to run	target binaries on build machine
Date: Tue, 31 Jul 2007 16:41:18 +0200	[thread overview]
Message-ID: <1185892878.1675.6.camel@localhost.localdomain> (raw)
In-Reply-To: <37c712e0707310727r2870246ei3cdeb275c7e21bb4@mail.gmail.com>


On Tue, 2007-07-31 at 10:27 -0400, Allan Clark wrote:
> Private reply reposted
> 
> On 7/31/07, Hans-Christian Egtvedt <hcegtvedt@atmel.com> wrote:
> >
> > On Tue, 2007-07-31 at 08:26 -0400, Allan Clark wrote:
> > > On 7/31/07, Thomas Lundquist <lists@zelow.no> wrote:
> > > > On Tue, Jul 31, 2007 at 10:22:03AM +0200, Hans-Christian Egtvedt wrote:
> > > > >
> > > > > As I said, it tries to execute moc, but moc is compiled for the target.
> > > >
> > > > Weird.
> > > >
> > > > > The problem arises when building the target Qtopia, it tries to use moc
> > > > > et.al compiled for the target architecture. And when running a
> > > > > big-endian AVR32 binary on my little-endian x86 laptop, it fails ;)
> > > >
> > > > But of course.
> > > >
> > > > the weird part is that the makefile was made for compiling qtopia on
> > > > ARM, which means moc & co was compiled for the right platform(s).
> > >
> > > ...but qmake and moc are supposed to run on the build host, not on the
> > > target.  They are only used during development, not during runtime.
> >
> > Then why is Qtopia a two stage build? Then only a normal cross-compile
> > is needed.
> 
> Not sure what you mean; perhaps I need to build the qtopia4 to check it.

The Qtopia 4 source is extracted to two different places and compiled
almost alike. As I see it, one time should be enough.

> Qmake is an "automake/autoconf" replacement, so any Qtopia4 app needs
> to be built with the qmake app, or the builder has to go track down
> the platform differences (like porting before automake and autoconf
> existed, or before Imake existed).  ince Qmake has to build the
> makefile for the target, it needs to run on the build host.
> 
> MOC creates the C++ base classes for the signal/event-passing in any
> QObject; it generates code that needs to be cross-compiled, but MOC
> runs on the buildhost.
> 
> MOC and Qmake link against Qtopia libraries -- they are themselves
> Qtopia applications.

Thanks for the description (-:

> Does that make sense?  Perhaps the two-stage is:
> 1) building libqt, qmake, and tools for host apps

Why does host apps need libqt? Qmake, moc, uic and rcc does not depend
on libqt.

> 2) running qmake and moc for the target

Do buildroot need this? Only if they are to be installed on target and
the user plans to build QT application on the target.

> 3) building libqt for the target

AFAIK Qtopia 4 is somewhat ready for cross compiling, capable of
building the tools with HOSTCC and the library with TARGETCC.

> In the end, 2 libqts are needed, plus a host-qmake, plus a host-moc.
> 
> I did this for Qt/E pre-2.2.0, but that's outdated now, and it's
> probably much more complex.

-- 
With kind regards,

Hans-Christian Egtvedt, siv.ing. (M.Sc.)
Applications Engineer - AVR32 System Solutions - Atmel Norway

  reply	other threads:[~2007-07-31 14:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-30 11:58 [Buildroot] Qtopia4 fails building - target stage tries to run target binaries on build machine Hans-Christian Egtvedt
2007-07-30 12:43 ` Bernhard Fischer
2007-07-30 18:54 ` Thomas Lundquist
2007-07-31  8:22   ` Hans-Christian Egtvedt
2007-07-31  9:38     ` Thomas Lundquist
2007-07-31 10:15       ` Hans-Christian Egtvedt
2007-07-31 12:26       ` Allan Clark
2007-07-31 12:35         ` Hans-Christian Egtvedt
2007-07-31 14:27           ` Allan Clark
2007-07-31 14:41             ` Hans-Christian Egtvedt [this message]
2007-08-01  7:45               ` Thomas Lundquist

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1185892878.1675.6.camel@localhost.localdomain \
    --to=hcegtvedt@atmel.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox