Cross-ld can not find libstdc ++. A, but shouldn't have looked
I am creating for arm-eabi (alias for arm-none-eabi) using GCC hosted on OS X and Debian. This code does not use C ++. However, the link does not work on Debian with
/opt/gnat-gpl-2015/bin/../lib/gcc/arm-eabi/4.9.3/../../../../arm-eabi/bin/ld: cannot find libstdc++.a
collect2: error: ld returned 1 exit status
This surprises me because the reported link line (c -Wl,-v
) doesn't mention libstdc++
either (see end).
Debian build doesn't have cross- libstdc++.a
, but OS X build (I don't know how this happened, it only contains empty_arm_object.o
). If I copy this one libstdc++.a
on the Debian side, the build works fine; but I would like to understand why this is necessary in the first place.
Command line links (in my opinion for clarity),
/opt/gnat-gpl-2015/bin/../lib/gcc/arm-eabi/4.9.3/../../../../arm-eabi/bin/ld \
-plugin \
/opt/gnat-gpl-2015/bin/../libexec/gcc/arm-eabi/4.9.3/liblto_plugin.so \
-plugin-opt=/opt/gnat-gpl-2015/bin/../libexec/gcc/arm-eabi/4.9.3/lto-wrapper \
-plugin-opt=-fresolution=/tmp/cctcp4CP.res \
-EL \
-X \
-o \
/home/simon/cortex-gnat-rts/test-stm32f4//testbed \
-L/home/simon/cortex-gnat-rts/test-stm32f4/.build/ \
-L/home/simon/cortex-gnat-rts/test-stm32f4/.build/ \
-L/home/simon/cortex-gnat-rts/test-stm32f4/../stm32f429i-disco-rtos/adalib/ \
-L/opt/gnat-gpl-2015/bin/../lib/gcc/arm-eabi/4.9.3/fpu \
-L/opt/gnat-gpl-2015/bin/../lib/gcc/arm-eabi/4.9.3/../../../../arm-eabi/lib/fpu \
-L/opt/gnat-gpl-2015/bin/../lib/gcc/arm-eabi/4.9.3 \
-L/opt/gnat-gpl-2015/bin/../lib/gcc \
-L/opt/gnat-gpl-2015/bin/../lib/gcc/arm-eabi/4.9.3/../../../../arm-eabi/lib \
testbed.o \
b__testbed.o \
/home/simon/cortex-gnat-rts/test-stm32f4/.build/last_chance_handler.o \
/home/simon/cortex-gnat-rts/test-stm32f4/.build/memory_streams.o \
/home/simon/cortex-gnat-rts/test-stm32f4/.build/containing.o \
/home/simon/cortex-gnat-rts/test-stm32f4/.build/dispatching.o \
/home/simon/cortex-gnat-rts/test-stm32f4/.build/iteration.o \
/home/simon/cortex-gnat-rts/test-stm32f4/.build/so.o \
/home/simon/cortex-gnat-rts/test-stm32f4/.build/streams.o \
/home/simon/cortex-gnat-rts/test-stm32f4/.build/strings.o \
/home/simon/cortex-gnat-rts/test-stm32f4/../stm32f429i-disco-rtos//adalib/libgnat.a \
/home/simon/cortex-gnat-rts/test-stm32f4/../stm32f429i-disco-rtos//adalib/libbsp-rtos.a \
-lgcc \
-Map /home/simon/cortex-gnat-rts/test-stm32f4/testbed.map \
-T /home/simon/cortex-gnat-rts/test-stm32f4/../stm32f429i-disco-rtos//adalib/stm32f429i-flash.ld
/opt/gnat-gpl-2015/bin/../lib/gcc/arm-eabi/4.9.3/../../../../arm-eabi/bin/ld: cannot find libstdc++.a
collect2: error: ld returned 1 exit status
The end of the linker script contains
/DISCARD/ :
{
libc.a ( * )
libm.a ( * )
libgcc.a ( * )
libstdc++.a ( * )
}
/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }
and the first is clear where the arm-eabi-ld
link to libstdc++.a
. I'm afraid these sections were blind copied from somewhere on the internet and I don't know what this first one is for. Is this "something libstdc++.a
you haven't already listed"?
source to share
The reason the linker was looking libstdc++.a
was because the library was mentioned in the linker script in the section /DISCARD/
.
It seems odd to include an entire file in a section /DISCARD/
whose purpose is to omit certain sections of the input. If you don't want to include the file, leave it on the command line!
Research has shown that in this case it ld
has unexpected behavior, including libc.a
the section /DISCARD/
has a very similar (if not identical) effect of including the -lc
link in the command line; and the command line used in this case ends -nostdlib -lgcc
. It should be -nostdlib -lgcc -lc
. This, together with the removal of the specific section /DISCARD/
, resolved the problem.
source to share