链接报错hidden symbol __aeabi_idiv (_divsi3.o) is referenced by DSO

更换新编译器时，链接报错。ld: xxx: hidden symbol `__aeabi_idiv' in libgcc.a(_divsi3.o) is referenced by DSO

ld: app: hidden symbol `__aeabi_idiv' in libgcc.a(_divsi3.o) is referenced by DSO

ld: final link failed: Bad value

查看__aeabi_idiv在libgcc.a里的信息：

arm-linux-gnueabihf-objdump -t libgcc.a | grep __aeabi_idiv

00000000 *UND*00000000 __aeabi_idiv0

00000000 g F .text00000000 .hidden __aeabi_idiv<--- g全局的，.hidden隐含的

00000294 g F .text0000001a .hidden __aeabi_idivmod

00000000 *UND*00000000 __aeabi_idiv0

00000000 *UND*00000000 __aeabi_idiv0

00000000 *UND*00000000 __aeabi_idiv0

00000000 w F .text0000000c .hidden __aeabi_idiv0

00000000 *UND*00000000 __aeabi_idiv

00000000 *UND*00000000 __aeabi_idiv

00000000 *UND*00000000 __aeabi_idiv

00000000 *UND*00000000 __aeabi_idiv

You should never use ld directly unless you know what you're doing, instead gcc or g++ drivers should be used because they know all the options which must be passed to the linker.

gcc supplies a few default options to ld.

ld doesn't know anything about C++, or any other language. ld has no idea what libraries your code needs to link with. If you try to link your compiled C++ code with ld directly, it'll bail out on you, since ld, by itself, has no idea where it can find libstdc++, gcc's C++ runtime library. Do you use strings? vectors? Most of that is template code that gets compiled as part of your object module. But there are a still few precompiled bits, in libstdc++, that need to be linked with.

When you give your compiled code to gcc to link, gcc will be courteous enough to pass all your files along to ld, and tell ld which libraries, in addition to any ones you explicitly specify.

You can link with ld directly, if you want to, as long as you specify the same libraries and link option gcc uses. But why would you want to do that? Just use gcc to link your gcc-compiled c ode.

结论：

将所有用ld的地方，改成用gcc，再编译正常。