__aeabi_* undefined references when linking

1,728 views
Skip to first unread message

Xavier Bigand

unread,
May 14, 2010, 10:19:47 AM5/14/10
to android-ndk
Hi,

I am currently trying to link my engine build as a static lib into my
game application build as shared library.
The engine is correctly build without errors and warnings.

I am getting some errors with __aeabi_* functions, I don't know how
fix it because it's not call directly in my code, it's seems to be
functions like SSE instructions.

localeconv() function is also missing, it defined in locale.h header.
I had allready remove a line that call missing decimal_point member of
structure lconv.

Here is details of errors:

SharedLibrary : libDracula_part1.so
out/apps/TeEngine/armeabi/libTeEngine.a(decode.o): In function
`th_decode_ctl':
/cygdrive/d/Softs/SDKs/Android/android-ndk-windows/apps/TeEngine/
project/jni/Common/Libs/libtheora/lib/decode.c:1998: undefined
reference to `__aeabi_lasr'
out/apps/TeEngine/armeabi/libTeEngine.a(decode.o): In function
`th_decode_packetin':
/cygdrive/d/Softs/SDKs/Android/android-ndk-windows/apps/TeEngine/
project/jni/Common/Libs/libtheora/lib/decode.c:2267: undefined
reference to `__aeabi_llsl'
/cygdrive/d/Softs/SDKs/Android/android-ndk-windows/apps/TeEngine/
project/jni/Common/Libs/libtheora/lib/decode.c:2131: undefined
reference to `__aeabi_llsl'
out/apps/TeEngine/armeabi/libTeEngine.a(state.o): In function
`oc_state_border_init':
/cygdrive/d/Softs/SDKs/Android/android-ndk-windows/apps/TeEngine/
project/jni/Common/Libs/libtheora/lib/state.c:327: undefined reference
to `__aeabi_llsl'
out/apps/TeEngine/armeabi/libTeEngine.a(llex.o): In function
`trydecpoint':
/cygdrive/d/Softs/SDKs/Android/android-ndk-windows/apps/TeEngine/
project/jni/Common/Libs/tolua++/dependences/lua/src/llex.c:179:
undefined reference to `localeconv'
collect2: ld returned 1 exit status
make: *** [out/apps/Dracula_part1/armeabi/libDracula_part1.so] Error 1
Build failed, exit with error code : 2

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

andrej sarkic

unread,
May 14, 2010, 1:28:51 PM5/14/10
to android-ndk
I don't know if this is exactly your issue, or how current the
information is, but it may point you in the right direction (i.e.
versions of libgcc)

http://groups.google.com/group/android-developers/browse_thread/thread/636d11723aae3117

David Turner

unread,
May 14, 2010, 3:42:20 PM5/14/10
to andro...@googlegroups.com
The __aeabi_xxx are normally part of libgcc.a, which must be placed at a special location in the final link command.
Is there any piece of code in your setup that was not generated with the NDK build scripts ? that could explain this.

Xavier Bigand

unread,
May 16, 2010, 8:46:14 AM5/16/10
to android-ndk
I finally fix it by adding -lgcc in Android.mk. I tough it was added
automatically.

On 14 mai, 21:42, David Turner <di...@android.com> wrote:
> The __aeabi_xxx are normally part of libgcc.a, which must be placed at a
> special location in the final link command.
> Is there any piece of code in your setup that was not generated with the NDK
> build scripts ? that could explain this.
>
> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/android-ndk?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/android-ndk?hl=en.

andrej sarkic

unread,
May 18, 2010, 11:01:52 AM5/18/10
to android-ndk
The Android team can give a more authoritative answer on this, but I'm
pretty sure you should not have to do that, and by doing so, your
library will likely havean incorrect ABI, and it could fail on future
versions of the OS. By adding -lgcc to your Android.mk you are putting
the libgcc in a different place on the link line (look for the command
build-shared-library in setup.mk).

nagamatu

unread,
May 19, 2010, 12:28:04 AM5/19/10
to android-ndk
On eclair, some of functions in libgcc.a is copied into libc.so and no
problem with these undefined __aeabi_xxxx. I assume this fix is not
included in 1.6 devices and 1.6 devices have a binary compatibility
problem.

http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=libc/arch-arm/bionic/libgcc_compat.c;h=886d025e56c8f1b1475f0005150f9446ecd87275;hb=HEAD#l29

--
nagamatu
> > > > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>

David Turner

unread,
May 19, 2010, 10:17:41 AM5/19/10
to andro...@googlegroups.com
This file is only useful to support code generated with old releases of the NDK.
If you use the current NDK properly, the generated code will not need to reference any of the libgcc functions that are embedded in libc.so and libm.so.

Which is why I think you're not using the NDK properly. My guess is that you have an external static library compiled independently (e.g. by directly calling the toolchain binaries, probably not with the right set of options).

Angus Lees

unread,
May 19, 2010, 8:35:14 PM5/19/10
to andro...@googlegroups.com
A quick check is: arm-eabi-nm -C -D yourlibrary.so
If you have any undefined __aeabi_* symbols (undefined is 'U' in nm output), then you've done something wrong.

If you can't use the NDK build system for any reason, the general principle is that gcc resolves outstanding symbols from all the '-l' libraries *in the order given on the commandline*.  So you want to make sure -lgcc appears at the point where you want all the  __aeabi_* symbols resolved.  Almost always this is at the end of your gcc link command line.  In the Android case, you probably want "<your libraries> -lgcc <any Android system libraries>".
(Again, if you are using the NDK build system, you don't need to worry your pretty little head about any of this)

 - Gus
Reply all
Reply to author
Forward
0 new messages