I installed STM32CubeIDE V2.0.0 on my M4 Mac laptop and tried to compile a project from my old Mac Intel laptop but it couldn't find the compiler:
/bin/sh: arm-none-eabi-gcc: command not found
I assumed I needed to install the compiler and the search AI's gave me a brew install recipe to do so. Once I installed the compiler and tried to compile, it recognized the compiler but I got a ton of messages about "cycolomatic complexity" and "stack usage" options not supported. I wiped all traces of the compiler, IDE and special directories again using AI recipes. But after once again following the steps carefully, I ended up at the same no pass.
I backed up a step and removed the compiler to take me back to the missing compiler message. I created a makefile.init to be run by make and placed a 'printenv' command in it to let me see the local environment that it was trying to compile in.
The PATH variable is the issue. It lists a path to a different version of the compiler which is not installed. The compiler is in a different directory
To fix it, I added a symbolic link for the directory that it was looking for to the one that exists:
ln -s com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.13.3.rel1.macos64_1.0.100.202509120712 com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.13.3.rel1.macos64_1.0.0.202411102158
And now it works!
The wrong path must come from somewhere - perhaps there is an internal setting that could be changed.
I am running the same version of the IDE on a different Mac Intel laptop and there is no problem. The correct compiler directory exists. My guess would be that the M4 install uses a directory for a different version of the compiler and internally when it creates the compile environment, it used the Intel compiler path. Perhaps the new compiler didn't get into the release? I don't know but very obscure bug. Thanks to these forum posts, I was able to reason it out and get a simple fix.
