[BUG] X-CUBE-SBSFU linker error with GNU Tools for STM32 (10.3-2021.10)

[fronders]

When compiling UserApp from 2_Images example application for NUCLEO-L476RG linker outputs the following error:

cannot use executable file '../../SBSFU/Debug/se_interface_app.o' as input to a link

arm-none-eabi-gcc -z max-page-size=1 -o "UserApp.elf" @"objects.list" ../../SBSFU/Debug/se_interface_app.o  -mcpu=cortex-m4 -T"../STM32L476RGTx.ld" --specs=nosys.specs -Wl,-Map="UserApp.map" -Wl,--gc-sections -static -Xlinker -L ../../Linker_Common --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
c:\st\stm32cubeide_1.0.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: cannot use executable file '../../SBSFU/Debug/se_interface_app.o' as input to a link
collect2.exe: error: ld returned 1 exit status
make[1]: *** [makefile:66: UserApp.elf] Error 1
make: *** [makefile:59: all] Error 2

I am using X-CUBE-SBSFU v2.5 on STM32CubeIDE v1.8.0 with GNU Tools for STM32 (10.3-2021.10).

However the issue disappears and build succeeds when using same IDE but with older toolchains - checked with both GNU Tools for STM32 (9-2020-q2-update) and GNU Tools for STM32 (7-2018-q2-update).

Attached is whole build output.

This is clearly related to this bin-utils bug report https://sourceware.org/bugzilla/show_bug.cgi?id=26223

And here you can see bin-utils have been patched to fix this error: https://sourceware.org/bugzilla/show_bug.cgi?id=26047

[Jocelyn RICARD]

Hello @fronders​,

thank you for raising the issue. The GNU Tools 2021 is not the default one provided in the installation. So, hopefully this will not impact too many people.

I transmit it internally.

Best regards

Jocelyn

[fronders]

Hello @Jocelyn RICARD​ 

Now that we have CubeIDE v1.9.0 released with GCC10 as default toolchain, are there any updates on the issue?

[Jocelyn RICARD · Accepted solution]

Hello @fronders​,

yes this limitation was handled internally.

Now, new SBSFU package will not be available before around 1 month.

The solution is currently available in the SBSFU provided in the STM32WL latest firmware package.

I have created a post here that explains how to fix this issue.

Best regards

Jocelyn

[fronders]

thanks a lot!!

[awiernie]

I have upgraded from STM32CubeIDE 1.8.0 to STM32CubeIDE 1.9.0 and there was gnu tools 10.3 (2021) installed by default. I have the same issue. The work around cannot be applied, as I use a third party postbuild.sh. I have already converted some workspaces to the new IDE. I see there is the older toolchain still in the plugins directory. Is it possible to use the 2020 toolchain without need to go back to the IDE 1.8.0? When will the new SBSFU be released?

[Jocelyn RICARD]

Hello @awiernie​ 

which postbuild.sh are you talking about ?

Just to be sure we are on same level of understanding.

The workaround I propose is adding a postbuid.sh at SBSFU generation.

I suspect you are talking about the other postbuild.sh launched after user image generation to create signed image. This is not incompatible.

Also, the new SBSFU release will implement the same mechanism as I shared.

Best regards

Jocelyn

[awiernie]

OK, I talked about the postbuild of the application.

I have now installed the 2020 toolchain and use this locally for that project now.

[fronders]

Hello @Jocelyn RICARD​ 

You mentioned back in March there would be a new SBSFU release upcoming, but none have been released so far. Can you please share an update on when it will be available?

Thanks