This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

The new toolchain is too bloated

I've been happily using the GNU Arm Embedded Toolchain for a while. Recently this was discontinued in favour of the Arm GNU Toolchain which combines both the embedded and non-embedded toolchains into a single package.

This bloats the installation to 5GiB on Windows! (Previously was under 1GiB).

Additionally GDB now depends on Python 2.7, which seems very backwards to me and complicates the installation process. (Previously there was a separate arm-none-eabi-gdb-py, which users were free to ignore if they didn't need the Python functionality).

These changes feel like a step in the wrong direction. My projects do not target ARM Linux, they only require an embedded ARM toolchain. I now feel that Windows users who might be interested in trying them are just going to give up because they don't have the bandwidth or hard disk space or just don't want to install an obsolete version of Python.

Would you consider splitting the toolchains up again?

(Apologies for the negative post, I do really appreciate that you folks maintain and make this toolchain available in the first place, but I felt I had to get this off my chest.)

Thanks,

Jeremy

Parents
  • > The majority came from our decision to stop using "strip" on the libraries

    so we're mostly talking about:

    400M    /usr/local/gcc-arm-none-eabi-10.3-2021.07/arm-none-eabi/lib/thumb/

    2.2G    /usr/local/gcc-arm-11.2-arm-none-eabi/arm-none-eabi/lib/thumb/

    The latter includes v7-a, v7-r, and v8-a, which weren't present and account for ~1G.

    > I realistically imagine there's not much that can be done for my users, other than forking the Arm GNU Toolchain

    By "fork", you mean "fork the source code and build from scratch"?  I'd think it would be much easy to download the current toolchain binaries and just "repackage" them to more closely match your needs (deleting unneeded libraries entirely, and "stripping" others)?

Reply
  • > The majority came from our decision to stop using "strip" on the libraries

    so we're mostly talking about:

    400M    /usr/local/gcc-arm-none-eabi-10.3-2021.07/arm-none-eabi/lib/thumb/

    2.2G    /usr/local/gcc-arm-11.2-arm-none-eabi/arm-none-eabi/lib/thumb/

    The latter includes v7-a, v7-r, and v8-a, which weren't present and account for ~1G.

    > I realistically imagine there's not much that can be done for my users, other than forking the Arm GNU Toolchain

    By "fork", you mean "fork the source code and build from scratch"?  I'd think it would be much easy to download the current toolchain binaries and just "repackage" them to more closely match your needs (deleting unneeded libraries entirely, and "stripping" others)?

Children
No data