[Pkg-electronics-devel] How is gcc-arm-none-eabi different from upstream GCC?

John Scott jscott at posteo.net
Sat Aug 12 16:06:36 BST 2023


On Sat, 2023-08-12 at 07:44 -0700, Keith Packard wrote:
> I'm not sure how that's supposed to work -- the usual process for
> building gcc takes three steps:
> 
>  1. Build GCC in bootstrap mode that skips compiling libstdc++.
>  2. Build the C library.
>  3. Build GCC in full mode that builds libstdc++ using the installed C
>     library.

It's relatively little-known which is a shame since it's such a cool feature, but when you take the top-level directories from any combination of Binutils, GCC, GDB, Newlib, and possibly glibc, and put them all into one giant directory, the top-level configure script automatically takes care of building all the right parts in the right order to attain the finished product. Doing this is also generally necessary if you want to run the GCC test suite (which is normally not possible when building a cross compiler, let alone a bare metal one, but it is possible if you build a GDB simulator at the same time).

This is what I do for gcc-sh-elf which, despite the source package name, builds libnewlib-sh-elf-dev and a simulator from GDB too. That's also awesome for another reason: it means we can build full-blown C programs like "Hello, world" that use stdio, invoke sh-elf-run (which is like Wine or qemu-user) and get it to print "Hello, world". It's magic!

For example, libssp (stack smashing protection) is part of GCC, but it depends on having an ISO C standard library for the target available. When you do a combined tree it will build most of GCC including libgcc, build Newlib (including automatically doing it for all the multilib targets), go back and build libssp, and when you're all done the GCC will be Newlib-aware.

That's a long-winded way of saying that using a combined tree approach is the way to go, avoids the need for build profiles, is more robust, and allows running build-time and DEP-8 tests.

> (that leaves aside the question as to why you'd want to revive newlib at all; it's not a great choice for embedded systems).
I'm looking to maintain the carl9170 firmware, the libre wireless firmware for AR9170 USB wireless adapters. It requires a cross toolchain with Newlib. I don't know whether another ISO C library would work, I'd rather stick to what upstream does.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20230812/9e600a77/attachment.sig>


More information about the Pkg-electronics-devel mailing list