Minimal GNU Arm Toolchain? [RESOLVED] - Page 1
Forum section: electronics / general

author: DELTA67
author_rank: Regular Contributor
timestamp: March 14, 2024, 10:53:25 am
content: 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

author: dobsonr741
author_rank: Frequent Contributor
timestamp: March 14, 2024, 01:56:04 pm
content: 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:FROM ubuntu:latest# Install required dependenciesRUN apt-get update && apt-get install -y \build-essential \git \wget \gnupg2 \&& rm -rf /var/lib/apt/lists/*# Import the missing public keyRUN 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-downloadsARG CPUARCHRUN 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 variablesENV PATH="/toolchain-none-elf/bin:${PATH}"ENV PATH="/toolchain-none-eabi/bin:${PATH}"ENV RPI=3# Set the working directoryWORKDIR /armbuildCMD ["./build.sh"]

author: krish2487
author_rank: Frequent Contributor
timestamp: March 14, 2024, 02:22:18 pm
content: 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..

author: DELTA67
author_rank: Regular Contributor
timestamp: March 14, 2024, 02:24:23 pm
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: March 14, 2024, 02:53:24 pm
content: 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 systemschoices!Enoughto 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.

author: DELTA67
author_rank: Regular Contributor
timestamp: March 14, 2024, 03:36:26 pm
content: 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"?

author: martinribelotta
author_rank: Regular Contributor
timestamp: March 14, 2024, 05:21:26 pm
content: QuoteAnd is growing up with each versionQuoteThe 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 directoryarm-none-eabi/lib/thumb/that contains all new cortex-m architecture (if you not use any non-cortex MCU maybe you remove the directoryarm-none-eabi/lib/armand 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)QuoteIdeally, you need to recompile gcc and toolchains by yourself. Some tools can help you for this likehttps://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=...)QuoteBtw, the gcc arm embedded is using newlib/newlib-nano. You can check the version in the archive fromarm-none-eabi/include/_newlib_version.hBy 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:find <directory of the toolchain> -name picolibc.specs

author: DELTA67
author_rank: Regular Contributor
timestamp: March 14, 2024, 05:27:48 pm
content: Thanks martinribelotta for the interresting infos !

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 14, 2024, 10:14:26 pm
content: 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.

author: langwadt
author_rank: Super Contributor
timestamp: March 14, 2024, 10:20:16 pm
content: what would be the point of spending even a minute saving 5 cents worth of storage space?

author: brucehoult
author_rank: Super Contributor
timestamp: March 14, 2024, 11:56:16 pm
content: Quote from: DELTA67 on March 14, 2024, 10:53:25 amI 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.

author: DELTA67
author_rank: Regular Contributor
timestamp: March 15, 2024, 09:56:01 am
content: Quote from: SiliconWizard on March 14, 2024, 10:14:26 pm+1Quote from: langwadt on March 14, 2024, 10:20:16 pmIt'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.

author: westfw
author_rank: Super Contributor
timestamp: March 16, 2024, 10:20:30 am
content: Don’t recent installs also include a large helping of CMSIS libraries that you may not be using?

author: voltsandjolts
author_rank: Unknown
timestamp: March 16, 2024, 10:28:04 am
content: Quote from: DELTA67 on March 15, 2024, 09:56:01 amYou 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

author: DELTA67
author_rank: Regular Contributor
timestamp: March 16, 2024, 12:27:09 pm
content: what's the difference between "bin/arm-none-eabi-gcc" and "arm-none-eabi/bin/gcc"?

author: Siwastaja
author_rank: Super Contributor
timestamp: March 16, 2024, 01:33:54 pm
content: Delete it completely, you are down to 0MB. It's clear at this point you will never get to using the thing anyway.

author: nctnico
author_rank: Super Contributor
timestamp: March 16, 2024, 01:39:28 pm
content: Quote from: DELTA67 on March 15, 2024, 09:56:01 amIf 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.

author: DELTA67
author_rank: Regular Contributor
timestamp: March 16, 2024, 03:54:39 pm
content: Quote from: nctnico on March 16, 2024, 01:39:28 pmI 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

author: westfw
author_rank: Super Contributor
timestamp: March 21, 2024, 07:20:19 am
content: QuoteNo, apparently not. That'll be another 300M or so. (also mostly binary libraries that you don't need.)

author: Nominal Animal
author_rank: Super Contributor
timestamp: March 21, 2024, 06:03:47 pm
content: Quote from: DELTA67 on March 16, 2024, 12:27:09 pmUsually nothing, one being either a symlink to or a copy of the other.Generally speaking, thegccexecutable internally executes a number of other programs, includingldfor linking. Because multiple installations of GCC can coexist on the same machine, eachgccinternally uses the full versioned names to execute the correct program for the target architecture.For example, I have botharm-none-eabi-andx86_64-linux-gnu-toolchains installed, each with their own programs likegcc,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 yourPATHenvironment variable to have the desired architecture-specific directory first in the search path, and you can use the short names (gccand so on) to refer to that architecture by default.

author: nctnico
author_rank: Super Contributor
timestamp: March 21, 2024, 06:58:14 pm
content: 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.

author: DELTA67
author_rank: Regular Contributor
timestamp: March 27, 2024, 03:20:40 pm
content: Quote from: nctnico on March 21, 2024, 06:58:14 pmThanks for the info but I don't want to change the directories hierarchy, just delete the extra programs.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 27, 2024, 07:52:37 pm
content: Quote from: DELTA67 on March 27, 2024, 03:20:40 pmThere 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?

author: peter-h
author_rank: Super Contributor
timestamp: March 27, 2024, 08:05:26 pm
content: ST Cube IDE is biggerMuch 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.

author: brucehoult
author_rank: Super Contributor
timestamp: March 27, 2024, 11:36:59 pm
content: Quote from: Siwastaja on March 27, 2024, 07:52:37 pmIn 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 27, 2024, 11:42:57 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 28, 2024, 07:45:04 am
content: Those were the daysI implemented CP/M 2.2 on a Z80, but on a Z180 I cheated and the BIOS was 64k and was banked-in when calledIn 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

author: DELTA67
author_rank: Regular Contributor
timestamp: March 28, 2024, 10:44:15 am
content: THANKS all for your contribution in this thread.As a conclusion It's more a waste of time than a waste of HDD space !