Difference between arm-linux-gnueabi and bcm2708?

[adammw]

Hi.
I'm trying to do some cross-compiling, could someone explain the difference between the

Code: Select all

arm-bcm2708-linux-gnueabi

compilers available from github vs the

Code: Select all

arm-linux-gnueabi

available on my ubuntu machine from the repositories (also the difference between

Code: Select all

arm-bcm2708hardfp-linux-gnueabi

vs

Code: Select all

arm-linux-gnueabihf

)?

Do they both produce compatible code, or is it that the generic ones require you to set cpu,vfp,etc. options when the bcm2708 ones don't, or is one more optimised, or one proprietary, or what?

Also, I've noticed that when I try to use

Code: Select all

arm-linux-gnueabihf

to cross compile I can't because it tells me:

Code: Select all

sorry, unimplemented: Thumb-1 hard-float VFP ABI

Also, this is all on Linux machines - is cross-compiling possible from a Mac?

Thanks.

[jecxjo]

What you are noticing is called a tuple. Compilers in the Unix world are labeled with a string that defines:

• Architecture
• Vendor
• Kernel
• System

The one found at github is configured in such a way that it should be the most optimum for an ARM BCM2708 family running Linux using GNU EABI. The second compiler you list is from Ubuntu and is built for ARM systems running Linux using GNU EABI. Since the Ubuntu people are looking to cover a larger, more generic market they provide a more generic compiler.

So whats the difference?
When it comes to compilers, GCC as an example, there many times a hundred or more tuning parameters that change the way a binary file is created from source. Some parameters are required. For example selecting Architecture (ARM, x86, SPARC), Endianness (Bit, Little), Bit size (8, 16, 32) or if the CPU contains a Floating Point Unit (Hardware, Software). Some parameters are optional and provide a specific "optimization" that makes your code run more efficient on a system with a very specific design.

If you want to make a compiler that will cover a larger group of hardware you build with only required parameters and maybe a few optimization that you know everyone can use. If you want to make the most fine tuned compiler that only works with your specific CPU then you set all the optimization you can to match your exact hardware.

Sometimes a CPU optimized compiler will work with a different family but typically you would use a more generic compiler in that case.

More info on EABI can be found here http://en.wikipedia.org/wiki/EABI#EABI

sorry, unimplemented: Thumb-1 hard-float VFP ABI

The compiler you've selected is configured to use Thumb supported commands to perform arithmetic using a Hardware Floating Point Unit.

A good explaination of what Thumb support is can be found here http://www.eetimes.com/discussion/other ... -ARM-thumb

tl;dr To reduce space needed for some ARM instructions, a subset of commands were reduced from 32bit instructions to 16bit. Takes up less space but requires support.

Also, this is all on Linux machines - is cross-compiling possible from a Mac?

Cross compiling is possible across architectures and Operating Systems. It does require a little more setup but it is definitely a viable option when trying to build applications for a much slower system. Use up those CPU cycles on your fast Mac rather than wait a long time to build it native on the Pi. I've never built a cross compiler on a Mac but I'm sure someone in this forum will have more info on that.

[plugwash]

Also, I've noticed that when I try to use

Code: Select all

arm-linux-gnueabihf

to cross compile I can't because it tells me:

Code: Select all

sorry, unimplemented: Thumb-1 hard-float VFP ABI

It seems the compiler is setup to generate thumb instructions by default and when you try and force it to build armv6 hardfloat code it tries (and fails since it's not a combination worth implementing) to build armv6 hardfloat thumb mode code. Try specifying -marm.

Also note that the float abi MUST match that of the system you are going to run the binary on. So binaries for running on debian armel need to use the softfloat abi (-mfloat-abi=soft or -mfloat-abi=softfp)

Finally make sure any static libaries you are building against (such as libgcc which is included in practically every gcc-built binary) are suitable for the Pi, ubuntu's libaries (whether armel or armhf) are built for armv7 and as such are NOT suitable for use on the Pi.

[andyroyal]

I've also been trying to cross compile arm-linux-gnueabihf from Ubuntu and hit the same Thumb-1 issue. If I use -marm it does compile, but when I copy the binary over to the Raspberry Pi (running Raspbian) and execute I get a segmentation fault every time. I guess this is the result of the static libraries being incompatible with armv6?

Is it fair to say that cross-compiling Ubuntu -> Raspbian is a non-starter? Are you aware of a different Linux distribution whose libraries are suitable for the Pi?

Should I just stop being so stubborn, concede defeat and compile natively on the Raspberry Pi?

[dom]

Should I just stop being so stubborn, concede defeat and compile natively on the Raspberry Pi?

You could use the tools in github, referenced in the first post.

[adammw]

Last time I checked, there was only binaries for Linux - Mac users were left out, no?

[dom]

Last time I checked, there was only binaries for Linux - Mac users were left out, no?

Run Linux from VirtualBox?

[plugwash]

I've also been trying to cross compile arm-linux-gnueabihf from Ubuntu and hit the same Thumb-1 issue. If I use -marm it does compile, but when I copy the binary over to the Raspberry Pi (running Raspbian) and execute I get a segmentation fault every time. I guess this is the result of the static libraries being incompatible with armv6?

It should work if you replace the static librararies with the corresponding raspbian ones.

[andyroyal]

It should work if you replace the static librararies with the corresponding raspbian ones.

That did the trick, thanks!

You could use the tools in github, referenced in the first post

I tried those, but couldn't get them to work - the gcc, g++, etc. executables were there, but when I tried to execute any of them I got "No such file or directory". I've just done a quick internet search and it looks like it might be something to do with the ELF interpreter or missing ELF dependencies, I'll have a go at fixing those this evening.

[andyroyal]

The problem was that the bc2708 executables on github are 32-bit, and I'm running 64-bit Ubuntu, so I needed to install a few 32-bit libraries. libc6-i386 and lib32z1 did the trick.

[kauschovar]

I've also been trying to cross compile arm-linux-gnueabihf from Ubuntu and hit the same Thumb-1 issue. If I use -marm it does compile, but when I copy the binary over to the Raspberry Pi (running Raspbian) and execute I get a segmentation fault every time. I guess this is the result of the static libraries being incompatible with armv6?

It should work if you replace the static librararies with the corresponding raspbian ones.

This is where I got stuck. I was able to compile on Ubuntu using:

Code: Select all

arm-linux-gnueabihf-gcc -marm

But I am getting segfaults when attempting to run it on the Raspberry Pi, as andyroyal reported. I don't know how to replace a static library. Is that something I have to do at compile time? Or is it something I have to do after copying the executable to the Raspberry Pi?

[andyroyal]

I don't know how to replace a static library. Is that something I have to do at compile time? Or is it something I have to do after copying the executable to the Raspberry Pi?

It's compile time. I copied the libraries to my VM somewhere I could get at them, then added some lines to my makefile so they could be found. So you'll need to do something along these lines:

Code: Select all

LDFLAGS += -L/usr/lib/arm-linux-gnueabihf
LDFLAGS += -L/opt/arm-linux-gnueabihf/vc/lib
LDFLAGS += -Wl,-rpath,/usr/lib/arm-linux-gnueabihf
LDFLAGS += -Wl,-rpath,/opt/arm-linux-gnueabihf/vc/lib

...

phantom_zone : phantom_zone.cpp
    $(GXX) $(CFLAGS) -g -o phantom_zone phantom_zone.cpp $(LDFLAGS) -lGLESv2 -lEGL -lbcm_host -lX11 -ljpeg

readelf can help tell you which libraries are needed.