我在OS X和Debian上使用GCC为arm-eabi (arm-none-eabi的别名)构建。相关代码不使用c++。但是，在Debian上使用
链接失败。/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
这让我很惊讶，因为报告的链接行(-Wl,-v)也没有提到libstdc++(见末尾)。
Debian构建没有交叉libstdc++.a，而OS X构建有(我不知道这是怎么发生的;它只含有empty_arm_object.o)。如果我复制这个libstdc++.a到Debian端，构建工作正常;但我想知道为什么首先需要它。
链接命令行(我希望为了清晰而编辑)是
/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
链接器脚本的结尾包含
/DISCARD/ :
{
libc.a ( * )
libm.a ( * )
libgcc.a ( * )
libstdc++.a ( * )
}
/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }
，第一个明显是arm-eabi-ld找到对libstdc++.a的引用。恐怕这些章节是从网上抄来的，我也不知道第一个章节是干什么用的。它是"任何从libstdc++.a，你还没有分配"?
链接器查找libstdc++.a的原因是链接器脚本在/DISCARD/部分中提到了该库。
在/DISCARD/部分中包含整个文件似乎很奇怪，其目的是省略输入的某些部分。如果您不想包含该文件，请将其排除在链接命令行之外!
调查显示，在这种情况下，ld有一个意想不到的行为，在/DISCARD/部分中包含libc.a与在链接命令行中包含-lc具有非常相似(如果不相同)的效果;本例中使用的link命令行以-nostdlib -lgcc结尾。应该是-nostdlib -lgcc -lc。这一点，加上删除特殊的/DISCARD/部分，解决了这个问题。