search

osx-cross / homebrew-arm

Pre-built GNU toolchain from ARM Cortex-M & Cortex-R processors (Cortex-M0/M0+/M3/M4/M7, Cortex-R4/R5/R7).
BSD 2-Clause "Simplified" License
152 stars 21 forks source link

arm-none-eabi-gcc@8: new formula #36

Closed fauxpark closed 2 years ago

fauxpark commented 2 years ago

A bit messy...

The newlib formula turns out to be pointless, because of the directory structure - a test compile failed as it couldn't find the specs files which are in a folder that doesn't get linked into opt. Instead, it must be compiled and installed in this formula.

I'm not 100% sure whether some of the flags are really needed. There are also some .la files that the cleaner misses, again because of the directory structure - it does not seem to look in prefix/arm-none-eabi/lib.

The test also is very basic. I'll work on it later. After that, I will see what happens if I just dupe the formula and bump the version.

29

ladislas commented 2 years ago

Looks like it worked! 👍 let me know when you're ready to merge :)

The newlib formula turns out to be pointless, because of the directory structure - a test compile failed as it couldn't find the specs files which are in a folder that doesn't get linked into opt. Instead, it must be compiled and installed in this formula.

Yep, seems to be the same avr-libc.

fauxpark commented 2 years ago

A simple QMK firmware on STM32F303, STM32F103, and STM32F411 all successfully enumerate. Comparing the filelist with that of the avr-gcc@8 formula, aside from the target-specific stuff, it looks like everything's being generated correctly.

I have also noticed the debug sections are not stripped in the avr-gcc formulae as is done here. I wonder if this information is actually useful, or if I should update them to match. The top-level AVR libgcc.a with the same objcopy command applied went from 7MB down to 1.8MB. avr-gcc has some .la files too, so I guess they are harmless, but I don't know if they're necessary either.

The test block I am still unsure of, ARM devices seem a little more complicated to get to blinky than AVR...

ladislas commented 2 years ago

The test block I am still unsure of, ARM devices seem a little more complicated to get to blinky than AVR...

I think compiling a simple C and C++ program with different available newlib features is sufficient.

I have also noticed the debug sections are not stripped in the avr-gcc formulae as is done here. I wonder if this information is actually useful, or if I should update them to match. The top-level AVR libgcc.a with the same objcopy command applied went from 7MB down to 1.8MB. avr-gcc has some .la files too, so I guess they are harmless, but I don't know if they're necessary either.

I must admit I'm a bit lost here, is that a good thing or a bad thing?

fauxpark commented 2 years ago

After some tinkering, I've concluded the test stuff is beyond my abilities at the moment. I may come back to it, but for now I think the --version check will have to do, even though Homebrew doesn't consider it a good quality test.

I must admit I'm a bit lost here, is that a good thing or a bad thing?

I guess it depends on whether it's particularly useful to be able to look into the standard libs while debugging your own code, rather than it just going into a black box.

fauxpark commented 2 years ago

@ladislas ready when you are :)