From: Ben Dooks <ben@fluff.org>
To: buildroot@busybox.net
Subject: [Buildroot] ARM EABI builds
Date: Wed, 27 Jun 2007 16:25:15 +0100 [thread overview]
Message-ID: <20070627152514.GS31791@trinity.fluff.org> (raw)
In-Reply-To: <20070627090329.GA3741@z1.synertronixx>
On Wed, Jun 27, 2007 at 11:03:29AM +0200, Konstantin Kletschke wrote:
> Am 2007-06-27 09:19 +0100 schrieb Ben Dooks:
>
> > I have finally tracked down the problem, and will be submitting a
> > fix as soon as I have reviewed the patch.
>
> *argh*
>
> I followed your thread and I am so sorry that I forgot that I for myself
> apply a patch regarding this issue. It floated around a while ago and
> it is called unbreak-armv4t.patch:
Whilst this is also a fix, I think that passing --with-cpu= to the
compiler at generation time is a better option. This will allow OABI
builds for any pre-armv4 sytems, and ensure that xscale/v5/v6/etc will
also produce optimal output as they will be configured with the correct
cpu architecture.
> ff -urN gcc-4.1.1/gcc/config/arm/linux-eabi.h gcc-4.1.1-arm9tdmi/gcc/config/arm/linux-eabi.h
> --- gcc-4.1.1/gcc/config/arm/linux-eabi.h 2006-10-22 11:11:49.000000000 -0700
> +++ gcc-4.1.1-arm9tdmi/gcc/config/arm/linux-eabi.h 2006-10-24 21:34:01.000000000 -0700
> @@ -45,7 +45,7 @@
> The ARM10TDMI core is the default for armv5t, so set
> SUBTARGET_CPU_DEFAULT to achieve this. */
> #undef SUBTARGET_CPU_DEFAULT
> -#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdmi
> +#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9tdmi
>
> #undef SUBTARGET_EXTRA_LINK_SPEC
> #define SUBTARGET_EXTRA_LINK_SPEC " -m armelf_linux_eabi"
>
>
> > The next thing is, do we then need to produce our compiler and
> > libraries in toolchain_arm_<cpu>_<fp> and build_arm_<cpu>_<fp> ?
>
> Well... why not? The toolchain_arm_<cpu>_<fp> directory is some sort of
> PIC in the filesystem and can moved around and used for crosscompiling
> other stuff standing alone.
That was more a request for comments, it can sometimes be difficult
to guage exactly how people view these things until you've asked.
It would also need EABI/OABI in there. I tried switching an already
configured buildroot from EABI to OABI, and found that it did not
build correctly (but that is for another post).
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
next prev parent reply other threads:[~2007-06-27 15:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-26 13:33 [Buildroot] ARM EABI builds Ben Dooks
2007-06-26 21:19 ` Tom
2007-06-26 22:25 ` Ben Dooks
2007-06-27 8:19 ` Ben Dooks
2007-06-27 9:03 ` Konstantin Kletschke
2007-06-27 15:25 ` Ben Dooks [this message]
2007-06-27 17:44 ` Tom
2007-06-28 10:34 ` Ben Dooks
2007-06-28 19:13 ` Tom
2007-06-29 13:52 ` Ben Dooks
2007-06-28 22:50 ` Ulf Samuelsson
2007-06-28 23:57 ` Tom
2007-06-29 13:53 ` Ben Dooks
-- strict thread matches above, loose matches on Subject: below --
2007-06-28 19:54 Stuart Wood
2007-06-28 23:01 ` Bernhard Fischer
2007-06-29 1:00 ` Tom
2007-06-29 9:31 ` Ben Dooks
2007-06-29 1:42 ` Alex Stewart
2007-06-29 7:16 ` Bernhard Fischer
2007-06-29 9:26 ` Ben Dooks
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=20070627152514.GS31791@trinity.fluff.org \
--to=ben@fluff.org \
--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