GCC
From Arctic Core - the open source AUTOSAR embedded platform
Arctic Studio ships a branded Cygwin installation and includes a working default compiler. However, if you for some reason wish you use another variant, you can get some pre-compiled variant or you can compile it yourself.
Contents |
Get a precompiled one
CodeSourcery provides some pre-compiled variants: [1]
Known good GCC combinations
The table below contains GCC versions that are known to work with Arctic Core:
| target | build environment | vendor | gcc | binutils | newlib | mpfr | gmp |
|---|---|---|---|---|---|---|---|
| ARM | mingw | ArcCore | 4.4.5 | 2.19 | 1.18 | 2.4.2 | 4.3.2 |
| ARM | cygwin | CodeSourcery | 4.3.3(2009q1) | ? | ? | ? | ? |
| ARM | Mac | Arc Core | 4.4.0 | 2.19.1 | 2.17 | ? | ? |
| PowerPC | cygwin | CodeSourcery | 4.3-50 | ? | ? | ? | ? |
| PowerPC | cygwin 1.5 | ArcCore Cygwin 1.5 | 4.1.2 | 2.19.1 | 1.16.0 | N/A | N/A |
| PowerPC | cygwin 1.7 | ArcCore Cygwin 1.7 | 4.1.2 | 2.19.1 | 1.16.0 | N/A | N/A |
| PowerPC | amd64-linux | Arctic Core Buildbot | 4.1.2 | 2.19.1 | 1.17.0 | N/A | N/A |
| PowerPC | Darwin x86_64 | ArcCore | 4.1.2 | 2.19.1 | 1.18.0 | N/A | N/A |
To build 4.3.0 and above you need at least MPFR 2.3.1 and GMP 4.2.2.
GCC object files sizes
PowerPC code is ~50% bigger than ARM thumb-2. Un-optmised(-O0) code is ~10-20% bigger than optimized(-O3, Os) code.
Space in Paths
There are two cases here.
- Space in tool installation path (path to gcc that is)
- Work ONLY on msys and cmd.exe on Windows. You can quote the path. E.g. CROSS_COMPILE="/c/A Path/bin/powerpc-eabi-" will probably work but not recommended.
- Space in path under your project.
- Will NEVER work as long as make is used on ANY platform. E.g. placing your project under "c:/My projects/arc" will NEVER work.
Path under Windows tools
CS - CodeSourcery
- CS GCC + MSYS = OK
- CS GCC + CYGWIN = SEMI-OK. Will have corrupted object path. e.g. c:/cygdrive/c...
- CYGWIN GCC + CYGWIN = OK. (Will have /cygdrive/x/ though)
When compiling under cygwin you get these pesky /cygdrive/X or even worse (c:\cygdrive\..) all over the object files. This can later be a problem when loading them into a debugger. Different problem areas:
- Using a GCC compiled under Cygwin.
- Using Codesourcery compiled GCC under Cygwin
Case 1
Object files get the following paths:
arch.c \cygdrive\c\ArcticSt... arch.h /cygdrive/c/ArcticSt... ...
For some reason the path have different slashes. But today it seems debuggers can handle cygwin paths one way or the other.
Case 2
Object files get the following paths
alarm.c C:\cygdrive\c\Arctic... arch.c C:\cygdrive\c\Arctic...
Ops, thats bad. Codesourcery seems to do a really bad job with the paths under Cygwin (or if it's cygpath?).
There is sadly no good way to fix this. You can substitute most/all $@ in rules.mk to something like:
$(subst /cygdrive/c,c:/,$@)
You will get paths that look like this (and can hopefully be loaded by the debugger)
counter.c C:\ArcticStud... create.c C:\ArcticStud...
Since make does not understand the "c:/" paths you have to remove the include for the dependency files (*.d files) (true or make 3.80+)