Linker from esp-13.2.0-20230928 cannot locate objects or libraries that are specified with absolute paths

[ccrause]

Issue submission guidelines

crosstool-NG version:

$ /home/christo/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32s2-elf-ld --version
GNU ld (crosstool-NG esp-13.2.0_20230928) 2.41
Copyright (C) 2023 Free Software Foundation, Inc.

host OS and its version

$ uname -a
Linux christo-Aspire-R3-131T 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

The Free Pascal compiler (FPC) supports many targets, including the esp32 series. The support was developed based on esp-idf v4.x toolchain and uses the SDK provided assembler and linker. This worked fine, until I tried to update support to esp-idf v5+ when the binutils version was updated to 13.2.0. The linker script that FPC generates includes absolute paths to the libraries and object files that should be linked. This method works for many different Gnu binutils versions across many different CPU and OS combinations.

Using the linker from 13.2.0 gives an error when provided with libraries specified with absolute paths. When libraries/objects are specified using relative paths (or no paths), the linker can locate them (if the correct search paths are also supplied of course). Below please find an example call to the linker using the linker script link.res (attached)the verbose output of the first error when passing a linker script as currently generated by FPC which contains absolute paths to the various libraries and objects (linker script: link.txt):

$ /home/christo/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32s2-elf-ld -g -b elf32-xtensa-le -m elf32xtensa --abi-windowed    --gc-sections  -Map /home/christo/fpc/xtensa/examples/hello/hello.map -L. -o /home/christo/fpc/xtensa/examples/hello/hello.elf -T /home/christo/fpc/xtensa/examples/hello/link.txt -u call_user_start_cpu0 -u ld_include_panic_highint_hdl -u esp_app_desc -u vfs_include_syscalls_impl -u pthread_include_pthread_impl -u pthread_include_pthread_cond_impl -u pthread_include_pthread_local_storage_impl -u newlib_include_locks_impl -u newlib_include_heap_impl -u newlib_include_syscalls_impl -u newlib_include_pthread_impl -u app_main -u uxTopUsedPriority -L /home/christo/fpc/xtensa/esp-idf-5.2.1/components/esp_rom/esp32s2/ld -T esp32s2.rom.ld -T esp32s2.rom.libgcc.ld -T /home/christo/fpc/xtensa/esp-idf-5.2.1/libs/esp32s2/memory.ld -T /home/christo/fpc/xtensa/esp-idf-5.2.1/libs/esp32s2/sections.ld -T esp32s2.rom.newlib-funcs.ld -T esp32s2.rom.newlib-data.ld -T esp32s2.rom.spiflash.ld -L /home/christo/fpc/xtensa/esp-idf-5.2.1/components/soc/esp32s2/ld -T esp32s2.peripherals.ld -T esp32s2.rom.api.ld --verbose > linker-verbose.log

The first error message is displayed (complete output in file linker-verbose.log):

/home/christo/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp-elf-ld: mode elf32xtensa
attempt to open /home/christo/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/../xtensa-esp-elf/home/christo/fpc/xtensa/examples/hello/lib/xtensa-freertos/hello.o failed

The problem seems to be caused by the linker wrongly appending the absolute path to hello.o to the path pointing to the toolchain's bin folder.
The linker does however successfully locate libraries in the toolchain lib folder, see below output:

attempt to open /home/christo/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/xtensa-esp-elf/lib/esp32s2/no-rtti/libm.a succeeded

For reference performing the same linking step as above but using the linker from toolchain 11.2.0 succeeds, see verbose output (linker-verbose-11.2.0.log).
Also, providing just the list of libraries and objects in the linker script (linknopath.txt) do succeed when using toolchain 12.2.0 (linker-verbose-12.2.0-nopath.log).

[Lapshin]

@ccrause , I suppose it's because they are not intended to be full paths in linker script.

See ld documentation https://sourceware.org/binutils/docs/ld/File-Commands.html#:~:text=%2C%20file%2C%20%E2%80%A6)-,INPUT(file%20file%20%E2%80%A6),-The%20INPUT%20command

[Lapshin]

The behaviour between 11.2.0 and 13.2.0 was changed because fix for https://github.com/crosstool-ng/crosstool-ng/issues/2126 was added

[ccrause]

@Lapshin, thank you for the explanation and references. It appears that the root cause of this issue is that sysroot is defined, which by design will append sysroot to a filename with a path starting with / (the situation leading to this issue). An unfortunate choice given that there are other alternatives to control when sysroot should be appended to paths.

Closing this issue since it is caused by upstream implementation details.