error linking to libgcc.a when cross-compiling for Android, but symbols exists?

Question

I am trying to cross-compile a very simple program for Android that worked with android-ndk-r6b and prior, but does not work on android-ndk-r7 and newer:

Answer 1

Here's your link like, broken out into multiple lines for clarity:

/home/gnychis/Documents/android/os/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../libexec/gcc/arm-eabi/4.4.3/collect2 \
  --sysroot=/usr/local/google/home/android/cupcake_rel_root \
  -X \
  -o test \
  -L/home/gnychis/Documents/android/android-ndk-r7b/platforms/android-9/arch-arm/usr/lib \
  -L/home/gnychis/Documents/android/os/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3 \
  -L/home/gnychis/Documents/android/os/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc
  -L/home/gnychis/Documents/android/os/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/../../../../arm-eabi/lib
  -T /home/gnychis/Documents/android/os/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/arm-eabi/lib/ldscripts/armelf.x \
  -dynamic-linker /system/bin/linker \
  --gc-sections \
  -z nocopyreloc \
  --no-undefined \
  -rpath-link=/home/gnychis/Documents/android/android-ndk-r7b/platforms/android-9/arch-arm/usr/lib \
  /home/gnychis/Documents/android/android-ndk-r7b/platforms/android-9/arch-arm/usr/lib/crtend_android.o \
  /home/gnychis/Documents/android/android-ndk-r7b/platforms/android-9/arch-arm/usr/lib/crtbegin_dynamic.o \
  /home/gnychis/Documents/android/os/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/lib32/libiberty.a \
  /home/gnychis/Documents/android/os/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/lib/gcc/arm-eabi/4.4.3/libgcc.a \
  -lc \
  -lm \
  /tmp/ccGAKjxX.o

As you can see, your own object file (the temporary one) is the very last item on the command line. This is just wrong. It needs to be before the libraries, at least, if it is to link correctly.

Basically, your agcc script is passing -nostdlib (which says that you know better) and then passing the libraries manually, but doing it in completely the wrong order. If you fix this, all should be well.

Link order is very important. Objects and libraries that provide symbols must be linked after objects and libraries that require symbols.

There were certain versions of the tools that could tolerate bad ordering, but I think that was a bug, or mis-feature, because newer toolchains cannot, and should not. Presumably this script was written for one of those.

Answer 2

Where to find: __aeabi_unwind_cpp_pr0 and other mysterious, undefined functions

(I had a similar problem error to what you describe, but found a different solution, that may be helpful to you or others)

I found 'libgccunwind.a' library in the Google NDK package which defines a number of these mysterious functions (they are functions referenced by libc.a and other libraries in the NDK package, but not defined in a standard library) I found them defined in a libgccunwind.a library in:

\sources\android\gccunwind\libs\armeabi

NM shows that they are defined in that lib from an 'unwind-arm.o' file:

nm libgccunwind.a

unwind-arm.o:
         U _GLOBAL_OFFSET_TABLE_
00000cf8 T _Unwind_Complete
00000cfc T _Unwind_DeleteException
00000ba4 T _Unwind_GetCFA
00000408 t _Unwind_GetGR
00000474 t _Unwind_SetGR
000003c4 T _Unwind_VRS_Get
0000084c T _Unwind_VRS_Pop
00000430 T _Unwind_VRS_Set
00000844 T __aeabi_unwind_cpp_pr0
0000083c W __aeabi_unwind_cpp_pr1
00000834 W __aeabi_unwind_cpp_pr2
         w __cxa_begin_cleanup
         w __cxa_call_unexpected
         w __cxa_type_match
         U __exidx_end
         U __exidx_start
00000d1c T __gnu_Unwind_Backtrace
         w __gnu_Unwind_Find_exidx

Independant of the libgccunwind.a above, I searched for __aeabi_unwind_cpp_pr0 and unwind-arm.c and unwind.c, and found various c source, for example:

http://lxr.free-electrons.com/source/arch/arm/kernel/unwind.c?a=arm

http://opensource.apple.com/source/gcc/gcc-5646/gcc/config/arm/unwind-arm.c

These programs seem to be derived from a similar source. My guess is that these 'unwind_cpp' (and related functions) are called by the functions in libc.a when a function returns or on certain events so that these functions can perform some debugging or tracing operation.

In any event, adding that directory in a -L linker option and -lgccunwind linker option (after the -lc linker option) allowed the linker to find those 'undefined' functions -- and let me get to the next problem I have in cross compiling to ARM systems.