Minimal GNU Arm Toolchain? [RESOLVED]

[DELTA67]

Hi all,
The complete installation of the GNU ARM Toolchain is over 400MB.
1- There are many folders : arm-none-eab, bin, lib, include, libexec and share.
What are those folders for? Can you please give me a short description of the files in each folder?
2- I want to strip down the toolchain to keep just a simple compiler-linker-objdump toolchain. What are the bare minimum folders and files I need to build C programs for cortex M3 and M4F?
3- How to know which C library is used by the toolchain (uclibc, newlib, newlib_nano, ...)? And how to replace it with another one?
Thanks

[dobsonr741]

How I dealt with the same concern: I created a docker build process, so it’s repeatable and I can remove the docker image containing the whole toolchain if no longer needed and bring it  back anytime, exactly it was. Opposite of tinkering with installing directly onto my daily use workstation. In other words, I don’t mind if it’s large, it will taking up space only  if I need it. And SSDs are cheap and fast.

Here is an example:

Code: [Select]

FROM ubuntu:latest

# Install required dependencies
RUN apt-get update && apt-get install -y \
    build-essential \
    git \
    wget \
    gnupg2 \
    && rm -rf /var/lib/apt/lists/*

# Import the missing public key
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C

# Download and install gcc-arm toolchain for the specified architecture
# https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

ARG CPUARCH
RUN if [ "$CPUARCH" = "x86_64" ]; then \
        wget -q    https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz \
        && tar -xvf *64-arm-none-eabi.tar.xz \
        && rm *64-arm-none-eabi.tar.xz \
        && wget -q https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-aarch64-none-elf.tar.xz  \
        && tar xf *-aarch64-none-elf.tar.xz \
        && rm *-aarch64-none-elf.tar.xz \
        && ln -s /arm-gnu-toolchain-13.2.Rel1-x86_64-aarch64-none-elf /toolchain-none-elf \
        && ln -s /arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi /toolchain-none-eabi; \
    elif [ "$CPUARCH" = "arm64" ]; then \
        wget -q    https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-aarch64-arm-none-eabi.tar.xz \
        && tar -xvf *64-arm-none-eabi.tar.xz \
        && rm *64-arm-none-eabi.tar.xz \
        && wget -q https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-aarch64-aarch64-none-elf.tar.xz \
        && tar xf *-aarch64-none-elf.tar.xz \
        && rm *-aarch64-none-elf.tar.xz \
        && ln -s /arm-gnu-toolchain-13.2.Rel1-aarch64-aarch64-none-elf /toolchain-none-elf \
        && ln -s /arm-gnu-toolchain-13.2.Rel1-aarch64-arm-none-eabi /toolchain-none-eabi; \
    else \
        echo "Unsupported architecture: $CPUARCH"; \
        exit 1; \
    fi

# Set environment variables
ENV PATH="/toolchain-none-elf/bin:${PATH}"
ENV PATH="/toolchain-none-eabi/bin:${PATH}"
ENV RPI=3

# Set the working directory
WORKDIR /armbuild

CMD ["./build.sh"]


[krish2487]

Bingo... docker makes it super easy to have reproducible dev environment.. and disk space is cheap..
and I much prefer to use the toolchains to make something over trying to optimize it..

[DELTA67]

Thanks dobsonr741 for your reply.
In fact the space the toolchain takes is not an issue, I'm using a standard HDD.
My philosophy is to keep only the minimal set of tools that does the job. On the other hand I want to know how the toolchain works under the hood.

[Jeroen3]

I think you're basically there with an install of gnu-arm as far as minimalism goes. I would not strip the installation package any further by hand, you may need some files when you start including things in your code that you removed.
The cross compilers are already packages quite minimalistic:
arm-gnu-toolchain-<GCC Major Version>.<GCC Minor Version>.[<Feature>-]{Alp|Bet|Rel}<Revision>-<Host>-<Target Triple>

For your other questions, there is a user manual: https://gcc.gnu.org/onlinedocs/
Yes, it's heavy stuff.

Anyway, soon you'll be looking at your minimalistic setup and thinking to automate things. Here is the fun part. Everyone does!
So you get many build systems choices! Enough to make you suffer in all ways possible.

What you can do is get some credits with GitLab and try to have your project compiled in one of their shared runners in the cloud (docker).
You need to specify exactly what you need, so there will not be much bloat. You don't want bloat because you pay for the time.

[DELTA67]

In the top bin folder there's: arm-none-eabi-gcc, arm-none-eabi-as, .... i.e the tools are prefixed with "arm-none-eabi".
In arm-none-eabi/bin folder the tools are NOT prefixed with "arm-none-eabi".
what's the difference between "bin/arm-none-eabi-gcc"  and "arm-none-eabi/bin/gcc"?

[martinribelotta]

Hi all,
The complete installation of the GNU ARM Toolchain is over 400MB.

And is growing up with each version

1- There are many folders : arm-none-eab, bin, lib, include, libexec and share.
What are those folders for? Can you please give me a short description of the files in each folder?

The most big directory is arm-none-eabi directory that contains all libraries for all variants (this is the real reazon of the grow with each version)



Specifically the directory arm-none-eabi/lib/thumb/ that contains all new cortex-m architecture (if you not use any non-cortex MCU maybe you remove the directory arm-none-eabi/lib/arm and save near of 30MB)

If you only need a cortex m3/m4 toolchain, you may be remove v7, v7-a*, v8-a*, v8*-m*, v7ve*, v7-r*, v6* and only maintain v7-m (cortex-m3 nonfp), v7e-m (cortex-m4 nonfp), v7e-m+fp (cortex-m4/m7 fp) and v7e-m+dp (cortex m4/m7 dp)

2- I want to strip down the toolchain to keep just a simple compiler-linker-objdump toolchain. What are the bare minimum folders and files I need to build C programs for cortex M3 and M4F?

Ideally, you need to recompile gcc and toolchains by yourself. Some tools can help you for this like https://crosstool-ng.github.io/ but in short, removing the directories in arm-none-eabi directory can save many space (but the compiler fail when you try to use some combination of -mcpu=... -mfpu=...)

3- How to know which C library is used by the toolchain (uclibc, newlib, newlib_nano, ...)? And how to replace it with another one?
Thanks

Btw, the gcc arm embedded is using newlib/newlib-nano. You can check the version in the archive from arm-none-eabi/include/_newlib_version.h

By example, the zephyr os toolchain uses picolibc (a derivative from newlib) and maybe seem similars but you can check if your compiler uses picolibc finding for this archives:

Code: [Select]

find <directory of the toolchain> -name picolibc.specs

[DELTA67]

Thanks martinribelotta for the interresting infos !

[SiliconWizard]

Yes the only thing you could do is delete the libraries for the targets you don't intend to use. If that's really useful.
I fully support the idea of getting rid of the bloat as much as possible, I'm not sure this is really a big benefit in this case, but that's your call. You'll have to do it all over again next time you update the toolchain. (You could probably write a script for that though.)

A more future-proof and less tinkery alternative would be to build your toolchain yourself and configure it to only build the targets you intend to use. I do that for my RISC-V toolchains.
If you only use C as well, you could configure GCC not to build the C++ front-end, which would further save both build time (for the toolchain) and space.

[langwadt]

what would be the point of spending even a minute saving 5 cents worth of storage space?

[brucehoult]

Hi all,
The complete installation of the GNU ARM Toolchain is over 400MB.

I just checked my RISC-V gcc newlib install. It's 666 MB.

Each of cc1, cc1plus, and lto1 (link time optimiser) are 130 to 145 MB, so that's just over 400 MB right there. gdb is 74 MB. There are a bunch of 5 MB each utility programs such as objdump and nm that you could conceivably delete. But I wouldn't.

Everything else is relatively small.

If you don't need C++ or LTO or GDB then you could delete those and save 350 MB. Or simply not build them in the first place (options to ./configure)

But, really, why do you care? With 64 GB SD cards now $10 and SSDs $15, half a GB of compiler stuff costs about 10c to keep around.

[DELTA67]

I fully support the idea of getting rid of the bloat as much as possible.

+1

what would be the point of spending even a minute saving 5 cents worth of storage space?

It's not a matter of saving space or some cents.
Uno: I've plenty of time, yes!!
Due: If we can do it why not?
Tri: It's an opportunity to know how things work under the hood.

[westfw]

Don’t recent installs also include a large helping of CMSIS libraries that you may not be using?

[voltsandjolts]

Uno: I've plenty of time, yes!!

You must be young, but all too quickly you'll be old and realise that time is a most precious commodity that needs to be used wisely. It's much more precious than disk space

[DELTA67]

what's the difference between "bin/arm-none-eabi-gcc"  and "arm-none-eabi/bin/gcc"?

[Siwastaja]

Delete it completely, you are down to 0MB. It's clear at this point you will never get to using the thing anyway.

[nctnico]

Tri: It's an opportunity to know how things work under the hood.

If that is your goal, then your time is much better spend on understanding how the linker descripter files work together with how GCC puts code and data into sections. After learning to write a bit of C and how to control peripherals, this is the third important thing to learn for an embedded software developer.

[DELTA67]

If that is your goal, then your time is much better spend on understanding how the linker descripter files work together with how GCC puts code and data into sections.

I know how the linker descripter files work together with how GCC puts code and data into sections.
https://www.bravegnu.org/gnu-eprog/index.html

[westfw]

Don’t recent installs also include a large helping of CMSIS libraries

No, apparently not.  That'll be another 300M or so. (also mostly binary libraries that you don't need.)

[Nominal Animal]

what's the difference between "bin/arm-none-eabi-gcc"  and "arm-none-eabi/bin/gcc"?

Usually nothing, one being either a symlink to or a copy of the other.

Generally speaking, the gcc executable internally executes a number of other programs, including ld for linking.  Because multiple installations of GCC can coexist on the same machine, each gcc internally uses the full versioned names to execute the correct program for the target architecture.

For example, I have both arm-none-eabi- and x86_64-linux-gnu- toolchains installed, each with their own programs like gcc, ld, objdump, et cetera.  Some of these are provided by "gcc", the rest by "binutils", the two together forming the basic toolchain.

The reason for having both the fully-versioned names and the short names is that you only need to set your PATH environment variable to have the desired architecture-specific directory first in the search path, and you can use the short names (gcc and so on) to refer to that architecture by default.

[nctnico]

One of the things to keep in the back of your mind is that gcc and the associated tools have the paths to other tools, libraries, includes and other files hardcoded inside the binaries (relative to the installation directory). This why including .h files and linking to system libraries works automagically without needing to specify the include and library paths. On one hand this makes life easy, on the other hands it obfustigates information about what is being included from where and which libraries are linked against.

[DELTA67]

One of the things to keep in the back of your mind is that gcc and the associated tools have the paths to other tools, libraries, includes and other files hardcoded inside the binaries (relative to the installation directory).

Thanks for the info but I don't want to change the directories hierarchy, just delete the extra programs.

[Siwastaja]

One of the things to keep in the back of your mind is that gcc and the associated tools have the paths to other tools, libraries, includes and other files hardcoded inside the binaries (relative to the installation directory).

Thanks for the info but I don't want to change the directories hierarchy, just delete the extra programs.

There are no "extra programs". Your one specific project might not use, say, nm, so you think you can save some hundred KB by deleting it, but then you are hunting a bug and want to see some information about your binaries, or want to sort functions by size, and google about it and they suggest you use nm, then what, you redownload the whole thing just to get nm back?

Or you delete files related to say Cortex-M4 architecture because you think you only do Cortex-M0, and then after two weeks you find that there is a good Cortex-M4 microcontroller which is perfect match for your project. Then what?

What you are doing is total waste of time. The toolchain already is pretty minimal, by today's standards. I remember the frustration of installing 10GB or so of random bullshit when doing Altera FPGA's in 2010, but 400MB in 2024 is a problem for you, are you serious?

[peter-h]

ST Cube IDE is bigger



Much of it is versions of libraries for different processors and for different selections of hardware v. software floats, etc. Hundreds of different builds...

Not worth spending time on sorting it out. It will take you hours just to find out which libc.a corresponds to what you are doing.

[brucehoult]

What you are doing is total waste of time. The toolchain already is pretty minimal, by today's standards. I remember the frustration of installing 10GB or so of random bullshit when doing Altera FPGA's in 2010, but 400MB in 2024 is a problem for you, are you serious?

In my day, sonny, we fit an entire Pascal OS, text editor, compiler, 6502 assembler, linker, and libraries, and your own project code, on two 140 KB floppy disks.

I recall Turbo Pascal 1.0 being a similar size and fitting on a 360k floppy, though I don't recall how much space was free. And I used it for z80 not 8086.

[SiliconWizard]

TP1.0 took about 32K of RAM to run IIRC on CP/M. I don't remember exactly the size of the full "distribution", but I think it was under 200K, all files included.

As to bloat and time wasted, that is true to a large extent, but the merit of tailoring your own toolchain goes beyond just saving a few tens of MB IMO - which is why I said that I thought configuring and building it yourself, for someone who wants more control, was way more beneficial that just trying to strip an existing one until it stops working. But it's all a matter of perspective and needs. I don't do that for ARM toolchains, but I do maintain my own RISC-V toolchain.

[peter-h]

Those were the days

I implemented CP/M 2.2 on a Z80, but on a Z180 I cheated and the BIOS was 64k and was banked-in when called

In this case I would be well stumped by the ~70 libc.a builds. It would be viable on a project which never changes except around the edges. I mean, you hardly need to update GCC, unless you feel bored and need work to find out why v n+1 is producing new warnings

[DELTA67]

THANKS  all for your contribution in this thread.
As a conclusion  It's more a waste of time than a waste of HDD space !