From: "Bradley D. LaRonde" <brad@ltc.com>
To: "Kevin D. Kissell" <kevink@mips.com>, <linux-mips@oss.sgi.com>
Subject: Re: Gcc v2.96 versus Trolltech QtEmbedded Window System
Date: Sat, 13 Jul 2002 08:15:56 -0400 [thread overview]
Message-ID: <003c01c22a67$0aab1ee0$4c00a8c0@prefect> (raw)
In-Reply-To: 023e01c22a5e$c013f120$10eca8c0@grendel
I've built qt 2.3.2 with various toolchains that I've built myself. Most
recently I built qt 2.3.2 for mipsel with binutils 2.12, gcc 3.1, and glibc
2.4.
Here is how I build my toolchains:
http://www.ltc.com/~brad/mips/mips-cross-toolchain
I configure qt starting like this:
./configure -xplatform linux-mips-g++
Regards,
Brad
----- Original Message -----
From: "Kevin D. Kissell" <kevink@mips.com>
To: <linux-mips@oss.sgi.com>
Sent: Saturday, July 13, 2002 7:15 AM
Subject: Gcc v2.96 versus Trolltech QtEmbedded Window System
> I am trying to build the GPL version of the Trolltech
> QT embedded windowing system on my Malta, using
> what I believe to be H.J. Lu's most recent tool chain:
>
> [root@localhost release-emb-generic]# g++ -v
> Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux-gnu/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110.1)
>
> The QT build process is a little unusual - the configure
> script causes a fairly huge (640KB) C++ source file
> to be generated, which is then thrown at the compiler.
> I would expect that to take a while, but after about
> 20 hours with zero output passed to the assembler
> stage (it runs with -pipe) and the gradual accretion
> of about 90MB of virtual memory (on my poor 32MB
> system) I concluded that it was probably trapped in
> an infinite loop. As I have seen this sort of thing occur
> in the past in optimizer stages, I hacked the makefile
> to replace -O2 with -O0. It hasn't run for 20 hours
> at -O0 yet, but after a couple of hours the memory
> allocation dynamic looks to be the same, only faster
> (72MB after only a couple of hours), so I'm not
> optimistic.
>
> My questions to the assembled panel of experts are:
>
> Are there known problems with gcc 2.96.110.1 in
> this regard?
>
> Is there a native toolchain that would be more
> likely to be able to handle the build of QT?
> I'm considering trying the 2.95 set on Maciej's
> site out of desperation.
>
> Has anyone succeeded in building QT Embedded
> for mips(el) Linux, either native or using cross-tools?
>
> Regards,
>
> Kevin K.
>
>
WARNING: multiple messages have this Message-ID (diff)
From: "Bradley D. LaRonde" <brad@ltc.com>
To: "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: Gcc v2.96 versus Trolltech QtEmbedded Window System
Date: Sat, 13 Jul 2002 08:15:56 -0400 [thread overview]
Message-ID: <003c01c22a67$0aab1ee0$4c00a8c0@prefect> (raw)
Message-ID: <20020713121556.k5mKi4k0NblRHaijo_pi9ZmUZNP6sIVtTVDGbU_JaXE@z> (raw)
In-Reply-To: 023e01c22a5e$c013f120$10eca8c0@grendel
I've built qt 2.3.2 with various toolchains that I've built myself. Most
recently I built qt 2.3.2 for mipsel with binutils 2.12, gcc 3.1, and glibc
2.4.
Here is how I build my toolchains:
http://www.ltc.com/~brad/mips/mips-cross-toolchain
I configure qt starting like this:
./configure -xplatform linux-mips-g++
Regards,
Brad
----- Original Message -----
From: "Kevin D. Kissell" <kevink@mips.com>
To: <linux-mips@oss.sgi.com>
Sent: Saturday, July 13, 2002 7:15 AM
Subject: Gcc v2.96 versus Trolltech QtEmbedded Window System
> I am trying to build the GPL version of the Trolltech
> QT embedded windowing system on my Malta, using
> what I believe to be H.J. Lu's most recent tool chain:
>
> [root@localhost release-emb-generic]# g++ -v
> Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux-gnu/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110.1)
>
> The QT build process is a little unusual - the configure
> script causes a fairly huge (640KB) C++ source file
> to be generated, which is then thrown at the compiler.
> I would expect that to take a while, but after about
> 20 hours with zero output passed to the assembler
> stage (it runs with -pipe) and the gradual accretion
> of about 90MB of virtual memory (on my poor 32MB
> system) I concluded that it was probably trapped in
> an infinite loop. As I have seen this sort of thing occur
> in the past in optimizer stages, I hacked the makefile
> to replace -O2 with -O0. It hasn't run for 20 hours
> at -O0 yet, but after a couple of hours the memory
> allocation dynamic looks to be the same, only faster
> (72MB after only a couple of hours), so I'm not
> optimistic.
>
> My questions to the assembled panel of experts are:
>
> Are there known problems with gcc 2.96.110.1 in
> this regard?
>
> Is there a native toolchain that would be more
> likely to be able to handle the build of QT?
> I'm considering trying the 2.95 set on Maciej's
> site out of desperation.
>
> Has anyone succeeded in building QT Embedded
> for mips(el) Linux, either native or using cross-tools?
>
> Regards,
>
> Kevin K.
>
>
next prev parent reply other threads:[~2002-07-13 12:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-13 11:15 Gcc v2.96 versus Trolltech QtEmbedded Window System Kevin D. Kissell
2002-07-13 11:15 ` Kevin D. Kissell
2002-07-13 12:15 ` Bradley D. LaRonde [this message]
2002-07-13 12:15 ` Bradley D. LaRonde
2002-07-13 16:00 ` H. J. Lu
2002-07-14 9:53 ` Kevin D. Kissell
2002-07-14 9:53 ` Kevin D. Kissell
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='003c01c22a67$0aab1ee0$4c00a8c0@prefect' \
--to=brad@ltc.com \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.