stm32cubeide V 2.1.1 crtn.o executable stack bug back again despite having -z noexecstack set

[rjenkinsgb]

Hi,

I encountered this bug with a previous update and after searching I added the -z noexecstack parameter as given in a 2025 post.

That cleared the problem at the time.

The IDE has updated itself to V2.1.1 and the bug has re-appeared, despite the noexecstack parameter still being present?

Full error:

C:/ST/STM32CubeIDE_1.19.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.win32_1.0.100.202602081740/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:/ST/STM32CubeIDE_1.19.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.win32_1.0.100.202602081740/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/thumb/v7e-m+dp/hard/crtn.o: missing .note.GNU-stack section implies executable stack
C:/ST/STM32CubeIDE_1.19.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.win32_1.0.100.202602081740/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/bin/ld.exe: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

(The IDE has been updated each time it prompted since the 1.19.0 install).

A second compile with no changes after clearing the error message completes OK, but this rather tedious when working on and debugging a big project.

Any work-around appreciated.

[Mahmoud Ben Romdhane · Accepted solution]

Hello @rjenkinsgb 

Let me thank you for your feedback.

This is a known limitation marked on STM32CubeIDE:STM32CubeIDE errata 2.1.x - stm32mcu.

As work around, I recommend that you add this flag -z noexecstack under (Project > Properties > C/C++ Build > Settings > MCU/MPU GCC Linker > Miscellaneous > Other Flags) and the build will be finished with 0 errors.

[See Attachment]

Thanks

Mahmoud

[rjenkinsgb]

Hi Mahmoud,

thanks for the reply.

I had previously added that flag, which is why I was confused that the error was still occurring.

What I did not notice until re-checking just now is that the flag settings are separate between debug and release builds, and I had only added it in one rather than both. so it re-appeared when I changed the build I was using.

I now have it set in both which will hopefully fix the problem for good!

Thanks again, Robert.