Compile programs for the Raspberry Pi 1 and Zero's ARMv6 SoC

[code_exec]

I was wondering how I can compile C++ programs for the original Pi and Pi Zero's ARMv6 SoC. According to https://chromium.googlesource.com/chrom ... ium_arm.md you can compile Chromium for ARM which I'd like to do because the Chromium build on Raspbian is out of date. But how do I compile Chromium for ARMv6 rather than ARMv7 so that it runs on all Pi models? Should I use https://packages.debian.org/stretch/gcc ... -gnueabihf

[DavidS]

Pretty simple, if you compile on a Raspberry 1B+ with the defaults it will build for the ARMv6.

[code_exec]

Pretty simple, if you compile on a Raspberry 1B+ with the defaults it will build for the ARMv6.

Chromium recommends you cross-compile for ARM because most ARM devices lack the RAM and power to build Chromium directly. For a 512MB ARMv6 SBC, I agree with this. How do I cross compile for ARMv6?

[jahboater]

Pretty simple, if you compile on a Raspberry 1B+ with the defaults it will build for the ARMv6.

Chromium recommends you cross-compile for ARM because most ARM devices lack the RAM and power to build Chromium directly. For a 512MB ARMv6 SBC, I agree with this. How do I cross compile for ARMv6?

Have you actually tried it?
Slowness is the problem, but for a one-off build, you will spend much longer trying to set up the cross compile.
You can compile huge projects on the Zero. It takes a few hours, but it does work. You can leave it running overnight.

Increasing the swap file size will help it through any brief periods when memory is over committed.

Code: Select all

sudo sed -i 's/^CONF_SWAPSIZE=[0-9]*$/CONF_SWAPSIZE=1024/' /etc/dphys-swapfile
sudo /etc/init.d/dphys-swapfile restart

The largest build I have ever done on the Pi Zero is the GCC compiler (larger than the Linux kernel). GCC in total is around 51 million lines of code to compile (17 million lines compiled three times) which takes about two days - but it works fine. Since I do that for every GCC release, I now cross compile on a Pi 3B+ which is easy and takes about 4.5 hours.

[code_exec]

I doubt it will work directly on any Pi, I am likely to get the following error when building:

Code: Select all

collect2: ld terminated with signal 6 Aborted terminate called after throwing an instance of 'std::bad_alloc'
collect2: ld terminated with signal 11 [Segmentation fault], core dumped

This is because of lack of RAM. See https://chromium.googlesource.com/chrom ... er-Crashes

[jahboater]

I doubt it will work directly on any Pi, I am likely to get the following error when building:

Code: Select all

collect2: ld terminated with signal 6 Aborted terminate called after throwing an instance of 'std::bad_alloc'
collect2: ld terminated with signal 11 [Segmentation fault], core dumped

This is because of lack of RAM. See https://chromium.googlesource.com/chrom ... er-Crashes

That would mean the linker is needing more than 2GB of memory

Perhaps look at the "--no-keep-memory" linker option.

Code: Select all

--no-keep-memory
   ld normally optimizes for speed over memory usage by caching the symbol tables of
   input files in memory.  This option tells ld to instead optimize for memory usage, by
   rereading the symbol tables as necessary.  This may be required if ld runs out of
   memory space while linking a large executable.

[code_exec]

I doubt it will work directly on any Pi, I am likely to get the following error when building:

Code: Select all

collect2: ld terminated with signal 6 Aborted terminate called after throwing an instance of 'std::bad_alloc'
collect2: ld terminated with signal 11 [Segmentation fault], core dumped

This is because of lack of RAM. See https://chromium.googlesource.com/chrom ... er-Crashes

That would mean the linker is needing more than 2GB of memory

Perhaps look at the "--no-keep-memory" linker option.

Code: Select all

--no-keep-memory
   ld normally optimizes for speed over memory usage by caching the symbol tables of
   input files in memory.  This option tells ld to instead optimize for memory usage, by
   rereading the symbol tables as necessary.  This may be required if ld runs out of
   memory space while linking a large executable.

I'd rather cross-compile rather than compile directly on a Pi. Even if it did work, it would take ages (probably a few days) it took eight hours to compile x64 Chromium on a laptop with 4 cores and 8GB RAM!

[n67]

I'd rather cross-compile rather than compile directly on a Pi. Even if it did work, it would take ages (probably a few days) it took eight hours to compile x64 Chromium on a laptop with 4 cores and 8GB RAM!

Agreed. I wish there were a simple, obvious, well-documented and easily downloadable cross-compiler toolchain available (for compiling Pi stuff on a regular computer).

Note that the stopgap - half-way there - solution is a cross-compiler toolchain that allows you to compile for the PiZero on a regular (3B-ish) Pi.

[DavidS]

There are advantages of using more powerful computers for compiling, though as you are talking about a desktop application the reasonable thing is to compile it on the desktop computer on which it will run, if it takes to long then blame the maintainers for there error of creating something of no use to human beings running reasonable systems.


I personally have a rule, that if it takes more than 4 hours to build on my current primarry RISC OS system it is to big to be of use, on any system. That includes for Linux stuff (if it will run RISC OS it will run Linux). This is part of why I like TCC even though TCC does not do any real optimization. I have thought about writing a simple pre-processor that would do some basic simple algorithmic optimization, and a peep-hole post compile optimizer for use with TCC, though probably will not do the first (I believe strongly in the philosophy that a programmer is responcible for providing the most effecient implementation of an algorithm, so high level profiling optimization is wasted code in a compiler).