f



Building GCC-4.1.1 C/C++ compiler for LPC3180 + VFP + Embedded Linux

Hello,

I want to have a cross compiler running on my win32 cygwin, that can
cross compile C/C++ code for LPC3180 with VFP to run on embedded linux.


I downloaded gcc-4.1.1 source onto win32 cygwin (I dont even know if I
downloaded the right compiler source for the job), and started reading
the instructions on how to compile the compiler.  First it says you
have to configure the build, then build the compiler.

I'm not an expert and there are so many configuration parameters to
configure the build before building the actual compiler, that I know
will take me 100 years to figure out.

Does anybody have a clue on how to configure the build, then do the
build to build the gcc compiler that cross compiles C/C++ code for
LPC3180 with VFP for embedded linux. 


Thanks 
Over my head

0
smaddy
9/29/2006 1:57:28 AM
comp.sys.arm 2071 articles. 1 followers. Post Follow

8 Replies
502 Views

Similar Articles

[PageSpeed] 16

smaddy <nsmith@islandlogix.com> wrote:
> Does anybody have a clue on how to configure the build, then do the
> build to build the gcc compiler that cross compiles C/C++ code for
> LPC3180 with VFP for embedded linux. 

Building a cross compiler is quite an involved process, it doesn't just
involve the compiler but the binutils as well. I recommend you download a
prebuilt tool chain from

http://www.codesourcery.com/gnu_toolchains/arm/download.html

-p
-- 
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------
0
Paul
9/29/2006 9:24:11 AM
"Paul Gotch" <paulg@at-cantab-dot.net> wrote in message
news:JOv*oMZrr@news.chiark.greenend.org.uk...
> smaddy <nsmith@islandlogix.com> wrote:
> > Does anybody have a clue on how to configure the build, then do the
> > build to build the gcc compiler that cross compiles C/C++ code for
> > LPC3180 with VFP for embedded linux.
>
> Building a cross compiler is quite an involved process, it doesn't just
> involve the compiler but the binutils as well. I recommend you download a
> prebuilt tool chain from
>
> http://www.codesourcery.com/gnu_toolchains/arm/download.html

seconded, except that I can't recomment the codesourcery version 'cos it's
badly broken. See for example problems with
__attribute__((interrupt("IRQ"))), which was sufficient for me to give up on
it.

Try GNUARM or WinARM unless you really need EABI.

Peter


0
Peter
9/29/2006 9:56:59 AM
Peter Dickerson <first{dot}surname@tesco.net> wrote:
> seconded, except that I can't recomment the codesourcery version 'cos it's
> badly broken. See for example problems with
> __attribute__((interrupt("IRQ"))), which was sufficient for me to give up on
> it.

Do you mean 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634

This is broken in mainline as well, it appears it has always been broken
therefore wasn't considered a regression. Both 4.1.x and 4.2.0 branches are
open for regression fixes only at the moment.

-p
-- 
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------
0
Paul
9/29/2006 12:04:12 PM
"Paul Gotch" <paulg@at-cantab-dot.net> wrote in message
news:Ojx*Vl0rr@news.chiark.greenend.org.uk...
> Peter Dickerson <first{dot}surname@tesco.net> wrote:
> > seconded, except that I can't recomment the codesourcery version 'cos
it's
> > badly broken. See for example problems with
> > __attribute__((interrupt("IRQ"))), which was sufficient for me to give
up on
> > it.
>
> Do you mean
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
>
> This is broken in mainline as well, it appears it has always been broken
> therefore wasn't considered a regression. Both 4.1.x and 4.2.0 branches
are
> open for regression fixes only at the moment.

I'd have to check the details but it looks like that one. *However* the
GNUARM and WinARM builds do not show this problem. In fact I didn't see this
in 3.4.3, 4.0.0, 4.1.0 or 4.1.1. I don't use the apcs-frame stuff though.
Perhaps there is some magic incantation of the command line that will fix it
codesourcery's version. Basically, I had a year of building code without
problem so I decided to try out the ARM supported version and found a code
gen fault immediately. My tolerance of code gen faults is zero - can't trust
it. Worst still, your saying they knew of the code gen fault and still let
it out the door! I'd be sacked if did that...

Peter


0
Peter
9/29/2006 3:55:29 PM
Peter Dickerson <first{dot}surname@tesco.net> wrote:
> I'd have to check the details but it looks like that one. *However* the
> GNUARM and WinARM builds do not show this problem.

I think you must be suffering from a different problem then since as far as
I know GNUARM is built from vanilla mainline sources. Either that or the
configure options that GNUMARM is built with somehow mask the problem.

> Worst still, your saying they knew of the code gen fault and still let
> it out the door! I'd be sacked if did that...

No I'm saying there exists a bug in the GCC bugzilla which may or may not be
your problem. Of which there are no comments from anyone at CodeSourcery
until well after the CodeSourcery 2006Q1 release was made.

All non-trivial compilers contain code generation faults most as a result of
incorrect optimisations. The compiler writer is only human after all. I
believe this particular fault has been lurking for a while because most
people using GCC have been writing their ISRs directly in asm rather than C,
plus while there is a real fault the originally reported fault was bogus as
the example code was wrong.

-p
-- 
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------
0
Paul
9/29/2006 5:05:40 PM
There is a binary for gcc c/c++ compiler 4.1.1 for cygwin at the bottom
of this link

http://www.gnuarm.com/files.html

Anybody knows if this is a good one?

What's EABI?

smaddy

Paul Gotch wrote:
> Peter Dickerson <first{dot}surname@tesco.net> wrote:
> > I'd have to check the details but it looks like that one. *However* the
> > GNUARM and WinARM builds do not show this problem.
>
> I think you must be suffering from a different problem then since as far as
> I know GNUARM is built from vanilla mainline sources. Either that or the
> configure options that GNUMARM is built with somehow mask the problem.
>
> > Worst still, your saying they knew of the code gen fault and still let
> > it out the door! I'd be sacked if did that...
>
> No I'm saying there exists a bug in the GCC bugzilla which may or may not be
> your problem. Of which there are no comments from anyone at CodeSourcery
> until well after the CodeSourcery 2006Q1 release was made.
>
> All non-trivial compilers contain code generation faults most as a result of
> incorrect optimisations. The compiler writer is only human after all. I
> believe this particular fault has been lurking for a while because most
> people using GCC have been writing their ISRs directly in asm rather than C,
> plus while there is a real fault the originally reported fault was bogus as
> the example code was wrong.
>
> -p
> --
> "Unix is user friendly, it's just picky about who its friends are."
>  - Anonymous
> --------------------------------------------------------------------

0
smaddy
9/29/2006 10:46:47 PM
"smaddy" <nsmith@islandlogix.com> wrote in message
news:1159570007.453088.51380@c28g2000cwb.googlegroups.com...
> There is a binary for gcc c/c++ compiler 4.1.1 for cygwin at the bottom
> of this link
>
> http://www.gnuarm.com/files.html
>
> Anybody knows if this is a good one?

I used it and the WinARM build with essentially identical results (see
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm). I have
had no problems at all to speak of. I'm using my own start up code with no
OS, mixing C and C++. I've built the whole project in Thumb and ARM code.
Thumb is my natural choice because I'm using an ARM7 with 16-bit external
bus.

> What's EABI?

It is a new application binary interface - the specification of how
functions are called, what parameters go where - that sort of thing. This is
a change from the orginal ABI. I don't know why the change is being made,
though. Perhaps Paul can enlighten us. The vanilla 4.1.1 uses the original
ABI. I think ARM Ltd are sponsoring the work that codesourcery are doing to
support this new EABI.

[snip]

Peter


0
Peter
9/30/2006 10:24:45 AM
Peter Dickerson <first{dot}surname@tesco.net> wrote:
> a change from the orginal ABI. I don't know why the change is being made,
> though.

There are several reasons however the most important is that it makes it
possible to link binaries produced by different compilers together.
Previously each compiler (and sometime different versions of the same
compiler) had its own incompatible ABI.

Modulo bugs it is possible to link binaries produced by any EABI compilers
together. Current EABI compilers include ARM RVCT, GCC 4.1.x and GreenHills
C/C++ for ARM.

> I think ARM Ltd are sponsoring the work that codesourcery are doing to
> support this new EABI.

ARM are a customer of CodeSourcery as can been seen from CodeSourcery's
customer page.

-p
0
Paul
9/30/2006 1:36:08 PM
Reply: