[BUG] Non-blocking make export error: missing gnu-elf.ld

[trns1997]

Description / Steps to reproduce the issue

When I configure for stm32f4discovery:nsh and then run make export, I get a warning about a missing linker script:

cp: cannot stat '/home/thomas/nuttxspace/nuttx/libs/libc/elf/gnu-elf.ld': No such file or directory

Despite this, the export archive is created successfully and the build is not blocked. It seems the export step is trying to copy a file that doesn’t exist anymore.

Steps to Reproduce:

1. Configure NuttX:

./tools/configure.sh -l stm32f4discovery:nsh

2. Run export:

make export

Output:

Create version.h
LN: platform/board to /home/thomas/nuttxspace/apps/platform/dummy
Register: hello
Register: dd
Register: nsh
Register: sh
CC:  chip/stm32_gpio.c chip/stm32_gpio.c:44:11: note: '#pragma message: CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py'
   44 | #  pragma message "CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py"
      |           ^~~~~~~
CC:  chip/stm32_flash.c In file included from chip/stm32_flash.c:40:
chip/stm32f20xxf40xx_flash.c:53:4: warning: #warning "Default Flash Configuration Used - See Override Flash Size Designator" [-Wcpp]
   53 | #  warning "Default Flash Configuration Used - See Override Flash Size Designator"
      |    ^~~~~~~
cp: cannot stat '/home/thomas/nuttxspace/nuttx/libs/libc/elf/gnu-elf.ld': No such file or directory

Notes:
The error is non-blocking and does not prevent the export archive from being created. I just wanted to check if this is an intentional leftover or something that should be cleaned up. I’d be happy to look into it further if needed.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Ubuntu 24.04

NuttX Version

master

Issue Architecture

[Arch: arm]

Issue Area

[Area: Configuring]

Host information

No response

Verification

• I have verified before submitting the report.

[acassis]

@leducp did you get that same issue on your board?

[trns1997]

@leducp did you get that same issue on your board?

@acassis it seems to occur on all boards, i tried with the xmc4800 and i have the same error when i export

[acassis]

@trns1997 that is strange because this file doesn't exist there, maybe it was there as was moved to other place:

$ find . -name gnu-elf.ld
./boards/risc-v/k230/canmv230/scripts/gnu-elf.ld
./boards/risc-v/litex/arty_a7/scripts/gnu-elf.ld
./boards/arm/stm32h7/stm32h750b-dk/scripts/gnu-elf.ld
./boards/arm/stm32h7/stm32h745i-disco/scripts/gnu-elf.ld
./boards/arm/stm32h7/linum-stm32h753bi/scripts/gnu-elf.ld
./boards/arm/sama5/jupiter-nano/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f470ik-eval/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f470zk-aiotbox/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f450zk-aiotbox/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f470zk-eval/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f450zk-eval/scripts/gnu-elf.ld
./boards/arm/csk6/csk6011a-nano/scripts/gnu-elf.ld
./boards/arm64/imx9/imx93-evk/scripts/gnu-elf.ld
./boards/arm64/qemu/qemu-armv8a/scripts/gnu-elf.ld
./boards/arm64/a527/avaota-a1/scripts/gnu-elf.ld

[leducp]

I have this problem on a recent version: I will try on an older one.

I think this file should be auto generated in most cases from "libs/libc/elf/gnu-elf.ld.in" and that's why you cannot find it with your search.

[leducp]

Here is the output using nuttx-12.7.0 commit 4ac2a5a (the one in use at my workplace):

P:➜  nuttx find . -name gnu-elf.ld
./binfmt/libelf/gnu-elf.ld
./libs/libc/modlib/gnu-elf.ld
./boards/arm64/qemu/qemu-armv8a/scripts/gnu-elf.ld
./boards/risc-v/litex/arty_a7/scripts/gnu-elf.ld
./boards/risc-v/qemu-rv/rv-virt/scripts/gnu-elf.ld
./boards/risc-v/k230/canmv230/scripts/gnu-elf.ld
./boards/arm/csk6/csk6011a-nano/scripts/gnu-elf.ld
./boards/arm/stm32h7/linum-stm32h753bi/scripts/gnu-elf.ld
./boards/arm/stm32h7/stm32h745i-disco/scripts/gnu-elf.ld
./boards/arm/sama5/jupiter-nano/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f450zk-aiotbox/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f470zk-eval/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f450zk-eval/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f470zk-aiotbox/scripts/gnu-elf.ld
./boards/arm/gd32f4/gd32f470ik-eval/scripts/gnu-elf.ld
P:➜  nuttx find . -name gnu-elf.ld.in

P:➜  nuttx make export

Create version.h
LN: platform/board to /home/leduc/Téléchargements/nuttx-12.7.0-rc0-4ac2a5a/apps/platform/dummy
Register: hello
Register: nsh
Register: sh
CC:  chip/stm32_gpio.c chip/stm32_gpio.c:41:11: note: '#pragma message: CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py'
   41 | #  pragma message "CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py"
      |           ^~~~~~~
CC:  chip/stm32_flash.c In file included from chip/stm32_flash.c:38:
chip/stm32f20xxf40xx_flash.c:51:4: warning: #warning "Default Flash Configuration Used - See Override Flash Size Designator" [-Wcpp]
   51 | #  warning "Default Flash Configuration Used - See Override Flash Size Designator"

So it seems that the bug was introduced 'recently'.

The file "gnu-elf.ld.in" was introduced by @anchao in April: maybe this is related (commit 5248221)?

[trns1997]

This bug started occurring since nuttx-12.9.0, all releases before this version show no sign of failing cp

[acassis]

Nice work @leducp ! @anchao could you please take a look?

[trns1997]

@acassis it is more this commit the real culprit: 657247b

[trns1997]

So mkexport.sh. The script still assumes that gnu-elf.ld always exists, but that file was removed and replaced with a template gnu-elf.ld.in. The actual gnu-elf.ld is only generated when CONFIG_LIBC_MODLIB=y (via modlib).

So during make export, if CONFIG_LIBC_MODLIB=n, the file never gets generated, and the script tries to copy something that doesn’t exist. That explains the warning we see.

A possible solution might be to update mkexport.sh to check for both cases:

APPLD=gnu-elf.ld
APPLDIN=gnu-elf.ld.in

if [ -f "${BOARDDIR}/scripts/${APPLD}" ]; then
  cp -f "${BOARDDIR}/scripts/${APPLD}" "${EXPORTDIR}/scripts/."
elif [ -f "${TOPDIR}/libs/libc/elf/${APPLD}" ]; then
  cp -f "${TOPDIR}/libs/libc/elf/${APPLD}" "${EXPORTDIR}/scripts/."
elif [ -f "${TOPDIR}/libs/libc/elf/${APPLDIN}" ]; then
  # Fall back to exporting the template if the real file is missing
  cp -f "${TOPDIR}/libs/libc/elf/${APPLDIN}" "${EXPORTDIR}/scripts/${APPLD}"
fi

This way:

If a board-specific or pre-generated gnu-elf.ld exists, it’s copied as before.

If only the .in template exists, it’s exported under the expected name so the export step doesn’t fail.

An alternative would be to trigger the generation of gnu-elf.ld from gnu-elf.ld.in inside mkexport.sh (when CONFIG_LIBC_MODLIB=y), but that feels heavier and could complicate the export flow. Falling back to the template seems like the safest minimal change.

Let me know what you guys think i can create a PR for this if you think the solution is acceptable.

[acassis]

@trns1997 nice catch. But I think you shouldn't force the generation of this gnu-elf.ld since CONFIG_LIBC_MODLIB is not enabled and probably some program will not be able to use it later.

The propser solution should be verifying if LIBC_MODLIB is enabled and only try to copy when it is enabled.

@anchao @leducp @yf13 comments?