Subject: [alpine-devel] Cross-compilers [was: Re: [alpine-aports] [PATCH 2/3] testing/gcc-arm-none-eabi: New aport]

From: Timo Teras <[email-masked]>
Date: Mon, 28 Aug 2017 10:09:50 +0300

Hi,

We've occasionally received requests for cross-compilers. And in fact
we do keep the *-avr variant already because we can't have native
building for it really nor run alpine on these microcontrollers.

Now ARM embedded is the second most popular, and many would benefit
from a cross compiler, probably me including.

I was earlier hopeful on getting an 'abuild build flavors' feature
where abuild could be used to automatically build several different
flavors of same APKBUILD - in cross-compiler case involving building
binutils & gcc for several different CTARGETs.

But as this feature has not been implemented yet, I'm writing to check
if anyone is working on it, or willing to work on it very soon. Or
should we open up to accept cross-compilers as separate APKBUILDs until
this feature is done?

Also, arm-none-eabi is also targetting bare-metal. So I wonder if this
should be separately added anyway. @ncopa, any thoughts if this
should/could reference the main 'gcc' or be separate like suggested in
the patch?

Thanks
Timo

On Sat, 26 Aug 2017 16:07:28 +0200
Marian Buschsieweke <[email-masked]> wrote:

> The GNU Compiler Collection for embedded ARM targets (e.g. Cortex
> M0/M3/M4/...) http://gcc.gnu.org

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Marian Buschsieweke <[email-masked]>
Date: Mon, 18 Sep 2017 18:10:35 +0200

Hi,

how about providing a single APKBUILD for all cross-compilers targeting
embedded bare-metal platforms and using subpackages to create the actual cross
compilers?

The attached APKBUILD implements this for gcc. The same should approach could
be applied to binutils, newlib (in case of non-AVR devices) and gdb (in case of
non-AVR devices). Also C++ support should be provided (at least for AVR
devices) to enable users to use Arduino. (Right now I disabled it for faster
packaging time.)

Btw: Is there a way to not create the base package?

Kind regards,
Marian

On Mon, 28 Aug 2017 10:09:50 +0300

---

From: Marian Buschsieweke <[email-masked]>
Date: Mon, 28 Aug 2017 10:33:58 +0200

Hi,

I need a ARM cross compiler for my work as PHD student, so I will maintain the
APKBUILDs for cross compiler toolchain anyway. Thus, it would be little afford
for me to keep seperate APKBUILDs in testing up to date until cross toolchains
can be created from a single APKBUILD.

Btw: The APKBUILDs were created to be reuseable for different bare metal
targets, simply changing the "_target" variable to "xtensa-lx106-elf" would
create a bare metal toolchain for ESP8266, sadly newlib does not provide
support for the xtensa ISA in the official source. I bet changing "_target" to
avr would work just as well.

> should/could reference the main 'gcc' or be separate like suggested in

I'd like to suggest to keep toolchains targetting bare metal architecture in a
separate APKBUILD from those targetting a full OS. E.g. java, go, Fortran,
objective C, Ada and (at least in my opinion, others see this different) C++ is
not really interesting for bare metal devices. Most languages (except C++, Ada
and Fortran) will not produce machine code that could be run on bare metal
devices and all but C++ will be a huge pain to even get packaged (if possible
at all).

Kind regards,
Marian

PS: In order to fuse arm embedded with AVR, enabling C++ would be required, as
a lot of users prefer Arduino to develop for the AVR platform. Maybe I should
add C++ before the APKBUILD gets accepted, if you choose to accept separate
APKBUILDs for different platforms for now.

---