gcc arm-none-eabi binaries don't run - macos

I build a cross compile toolchain on OSX with:
binutils-2.23.52
gcc-4.6.4
gcc-core-4.6.4
gcc-g++-4.6.4
gdb-7.6.1
gmp-4.3.2
mpc-1.0.1
mpfr-2.4.2
newlib-2.0.0
for the target EFM32 wich is a ARM Cortex-m3, so the gcc target is arm-none-eabi.
All compiled fine.
But making programs with this toolchain like blink.c don't actually run on the EFM32 board.
I checked the blink.bin I did with a binary created with a IAR commercial toolchain delivered in the demos from energymicro, also gcc based and the they look very different internally (as expected :).
So has my toolchain wrong libs/versions or is it simply a matter of gcc/ld/ar switches wrong and what would be the steps to systematicly analyse this?

Related

Identify Compiler Versions with arm-none-eabi cross compiling

I'm trying to figure out the compiler versions that are used in my project (to sync them across the team).
I'm using ChibiOS on an STM32 and it uses a makefile to compile. In the Makefile it uses
TRGT = arm-none-eabi-
CC = $(TRGT)gcc
Which makes it clear that arm-none-eabi-gcc is being used. However unclear to me is, if the version of my gcc compiler (gcc --version) is at all relevant to the compilation. As far a I understand gcc just is being set to a specific target here? Whats the relationship between my gcc/cc executable and the arm-none-eabi-gcc executable?
There is no relationship. It is a separate compiler which usually comes with its own include files, libraries, startup file and linker scripts. Usually, it is called a toolchain as often it comes with other tools as well (linker, specific versions of gdb and other tools).

Issues in Cross compiling when linking GMP to GCC

Using the How To Build GCC 4.8.2 ARM Cross-Compiler, I have installed and setup everything and it works just fine as mentioned in the post i.e., I was able to cross compile a simple C code. But, when I try to compile a simple GMP code, I get this error.
fatal error: gmp.h: No such file or directory
Compilation terminated
How should I fix this? My goal is to compile a gmp program. If possible, refer me to good tutorials.
Thanks!
If you want GMP compiled for the target system (ARM), you must compile it by itself using the newly built cross-compiler, not as a part of building GCC. GMP (along with MPFR, MPC, ISL, CLooG, etc.) being placed in the GCC toplevel source directory simply means that it gets compiled and linked for the cross-compiler you're building.
Since the cross-compiler will run on the host system, GMP will also be compiled for the host system, else linking the library would fail, and you wouldn't get a cross-compiler. It may sound silly, but there are reasons for doing it this way, such as buggy prebuilt packages provided by the package manager on the host system or merely to avoid installing those libraries on the host system when all you want is the cross-compilation toolchain.

Is newlib for building cross compiler for powerpc e500mc mandatory?

I am trying to build a cross compiler for PowerPC e500mc with target powerpc-e500mc-eabi. As some websites mentioned, i built an bootstrap compiler first. and then tried to compile newlib with it. But i got some error like,
/bin/sh: powerpc-e500mc-eabi-cc: command not found
I want to know, can we directly compile GCC cross compiler without newLib. Also, can anyone tell me the exact pre-requisites for powerpc e500mc architecture. I have GMP, MPC, MPFR, BinUtils not sure whether newLib required or not.
You can build gcc without any C library, there is no need for newlib. Please find a list of dependencies from a crosstool-ng build below.
1. Alternatives
You can build everything manually, what you obviously attempted to do. This is possible but there are various constraints to keep in mind, for instance builds might fail if your filesystem is not case sensitive or if you build inside your source directory. Besides all the dependencies and their versions.
You let crosstool-ng build your cross toolchain. Crosstool-ng is mostly self-contained with few external dependencies. It will download and build all dependencies in the right versions for you, and it comes with various sample configurations. It will check for obstacles like a case insensitive filesystem. It lets you configure your cross toolchain in a similar way you configure a Linux kernel. I've built various cross toolchains by means of it for several years on several host systems without trouble, including Linux, OS X (homebrew) and Windows (cygwin). You find it here: http://crosstool-ng.org/.
I'm going to line out the steps that it takes to build a cross toolchain by means of crosstool-ng. I tested this setup on Windows (cygwin) today with the crosstool-ng from git.
2. Download crosstool-ng, build and install it.
Follow the steps in
docs/2 - Installing crosstool-NG.txt.
3. Configure your cross toolchain.
Follow the steps in
docs/3 - Configuring a toolchain.txt.
4. Example
mkdir powerpc-e500v2-eabi
cd powerpc-e500v2-eabi
ct-ng powerpc-e500v2-linux-gnuspe
The last step will create a configuration from a sample which I thought is similar enough to what you want. In the next step, we will adapt this configuration, the criteria are
no operating system
no C library
EABI
you want e500mc, the sample is e500v2. I leave it up to you to adapt the configuration to it.
4.1. Configuration
ct-ng menuconfig
Operating System
Target OS
Select bare-metal
C-library
C library
Select none
Target options
ABI
Select EABI
C-Compiler
gcc version
Select 5.1.0 (the sample configured a gcc 4.6.4
here)
Deselect C++ (since you do not want a C library
either and it'd pull extra dependencies)
Debug facilities
Deselect gdb (unless you want it, can pull extra dependencies)
4.2. Build
ct-ng build.4
Crosstool-ng will download and build the following dependencies.
gmp-6.0.0a
mpfr-3.1.2
isl-0.14
mpc-1.0.2
binutils-2.25
gcc-5.1.0
It will install the cross toolchain in
${HOME}/x-tools/powerpc-e500v2-eabi.
You can specify a different install prefix in the configuration.
This build issue can be fixed by creating a symlink powerpc-e500mc-eabi-cc pointing to powerpc-e500mc-eabi-gcc.

Why do cross-compilers have a two stage compilation?

I currently try to understand how cross-compilers work. I'm a bit confused about the two-staged compiler compilation process.
As far as I read, the following procedure is applied:
Compile bintutils for the target architecture
Compile GCC (stage 1)
Compile newlib/eglibc/... with GCC
Compile GCC with the libc (stage 2)
Why is there a second stage involved? Couldn't I just invoke the first stage compiler with some flag like -lc to include libc?
I'm not sure why gcc has such a complicated build process. My clang/LLVM based ELLCC (http://ellcc.org) cross tool chain project builds like this:
Compile the compiler (using either gcc or a pre-built version of the ELLCC compiler available from the web site.).
Use the compiler to build the C++ and C libraries for all targets.
Build binutils and gdb for all targets (for all targets: don't make target specific utilitities except for the assemblers. ld, gdb, objdump, etc. all support this)
(optional) Use your newly built compiler to cross build itself for all the targets.
BTW, ELLCC currently supports ARM, Microblaze, Mips, PowerPC, and x86 targets for Linux and bare metal execution environments.

gcc dll - compiled under Linux

I have a project written in gcc - bison -flex on Linux environment. All the project is implemented into a *.so file and is called from python-tkinter graphic surface.
There is a need to run it on windows. However I'd avoid to install all the windows equivalent of gcc - bison -flex programs.
Is it possible to force gcc IN LINUX ENVIRONMENT to compile WINDOWS DLL instead of *.so? It could make life easier to use the same technics as I do now: just do calls from python-tkinter graphic surface.
You can, of course, cross-compile it.
You'll need some packages installed, though.
Your normal project would be able to build if you use the MINGW equivalent of GCC for the target architecture.
Also, take a look at this:
Manual for cross-compiling a C++ application from Linux to Windows?
The linking can be kind of troublesome though, since it could come a time where softlinking fails due to versions. In that case you'll need to create some symbolic links to the correct version.
The output of the compilation process should be with -o DYNAMIC-LIBRARIE-NAME.dll and of course use the -shared flag.
Hope it gives you some pointers..
Regards.

Resources