Cross Compiling GSL for Android

I am attempting to cross compile the GNU Scientific Library (GSL) for Android 4.1 using Autotools. My build and host are as follows:

build="i386-apple-darwin10.8.0"
host="arm-linux-androideabi"

Autotools versions:

GNU Automake version 1.11.3
GNU Autoconf version 2.68
GNU Libtool version 2.4.2

My goal is to compile an executable that I can run from a shell on an emulated device. Thus far, I have compiled GSL and my executable using a toolchain that I generated using the Android Native Development Kit (NDK). I then pushed the shared libraries 'libgsl.so.0' and 'libgslcblas.so.0'(both of which are listed in the dynamic section of my executable) to '/system/lib' and the executable to the device.

Here is the the output of arm-linux-androideabi-readelf -d issm.exe

Dynamic section at offset 0x26a2a4 contains 26 entries:
Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libgsl.so.0]
0x00000001 (NEEDED)                     Shared library: [libgslcblas.so.0]
0x00000001 (NEEDED)                     Shared library: [libm.so]
0x00000001 (NEEDED)                     Shared library: [libc.so]
0x00000001 (NEEDED)                     Shared library: [libdl.so]
0x0000000f (RPATH)                      Library rpath: [/Users/gperez/issm/issm-uci/trunk-jpl/externalpackages/gsl/install/lib]
0x00000020 (PREINIT_ARRAY)              0x26d000
0x00000021 (PREINIT_ARRAYSZ)            0x8
0x00000019 (INIT_ARRAY)                 0x26d008
0x0000001b (INIT_ARRAYSZ)               1100 (bytes)
0x0000001a (FINI_ARRAY)                 0x26d454
0x0000001c (FINI_ARRAYSZ)               8 (bytes)
0x00000004 (HASH)                       0x8128
0x00000005 (STRTAB)                     0x96a0
0x00000006 (SYMTAB)                     0x87f0
0x0000000a (STRSZ)                      3588 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000015 (DEBUG)                      0x0
0x00000003 (PLTGOT)                     0x27239c
0x00000002 (PLTRELSZ)                   960 (bytes)
0x00000014 (PLTREL)                     REL
0x00000017 (JMPREL)                     0xa7ec
0x00000011 (REL)                        0xa4a4
0x00000012 (RELSZ)                      840 (bytes)
0x00000013 (RELENT)                     8 (bytes)
0x00000000 (NULL)                       0x0

I realize that the RPATH is incorrect, but if I understand the dynamic linker correctly, then it should fail to find the needed libraries in RPATH and then proceed to check LD_LIBRARY_PATH, where all the libs are situated.

I then proceeded to run my executable, but I was surprised to find the following linking error:

link_image[1936]:   468 could not load needed library 'libgsl.so.0' for './issm.exe' (reloc_library[1285]:   468 cannot locate 'cblas_ctrmv'...
)CANNOT LINK EXECUTABLE

This error lead me to check the contents of 'libgsl.so.0' which are as follows:

Relocation section '.rel.plt' at offset 0x36014 contains 161 entries:
Offset     Info    Type            Sym.Value  Sym. Name
00201c54  00002316 R_ARM_JUMP_SLOT   00000000   cblas_ctrmv
00201c58  00002f16 R_ARM_JUMP_SLOT   00000000   cblas_zswap
00201c5c  00003816 R_ARM_JUMP_SLOT   00000000   cblas_zsymm
00201c60  00005016 R_ARM_JUMP_SLOT   00000000   cblas_cgeru
00201c64  00009216 R_ARM_JUMP_SLOT   00000000   cblas_sgemm
00201c68  00009c16 R_ARM_JUMP_SLOT   00000000   cblas_ctrsv
00201c6c  0000c316 R_ARM_JUMP_SLOT   00000000   cblas_sgemv
...

The corresponding '.dynsym' of 'libgslcblas.so.0':

Symbol table '.dynsym' contains 233 entries:
Num:    Value  Size Type    Bind   Vis      Ndx Name
...
218: 0004e148    64 FUNC    GLOBAL DEFAULT    7 __aeabi_f2d
219: 00050314     0 NOTYPE  GLOBAL DEFAULT   12 __data_start
220: 0000d69c  1604 FUNC    GLOBAL DEFAULT    7 cblas_dgbmv
221: 0002e008  3540 FUNC    GLOBAL DEFAULT    7 cblas_ctrmv
222: 00042c34  4184 FUNC    GLOBAL DEFAULT    7 cblas_ztbmv
223: 0004de4c   688 FUNC    GLOBAL DEFAULT    7 __subdf3
224: 00003dc4   284 FUNC    GLOBAL DEFAULT    7 cblas_snrm2
...

Since the very first entry in the Relocation section '.rel.plet' causes the linking to fail, the problem is likely to be with all 'cblas' symbols. I then decided to look at the the Dynamic section of 'libgsl.so.0'

Dynamic section at offset 0x200b60 contains 25 entries:
Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libm.so]
0x00000001 (NEEDED)                     Shared library: [libc.so]
0x00000001 (NEEDED)                     Shared library: [libdl.so]
0x0000000e (SONAME)                     Library soname: [libgsl.so.0]
0x00000010 (SYMBOLIC)                   0x0
0x0000000f (RPATH)                      Library rpath: [:/Users/gperez/issm/issm-uci/trunk-jpl/externalpackages/gsl/install/lib]
0x00000019 (INIT_ARRAY)                 0x200c68
0x0000001b (INIT_ARRAYSZ)               8 (bytes)
0x0000001a (FINI_ARRAY)                 0x200c70
0x0000001c (FINI_ARRAYSZ)               12 (bytes)
0x00000004 (HASH)                       0xb4
0x00000005 (STRTAB)                     0x19b1c
0x00000006 (SYMTAB)                     0x860c
0x0000000a (STRSZ)                      107542 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000003 (PLTGOT)                     0x201c48
0x00000002 (PLTRELSZ)                   1288 (bytes)
0x00000014 (PLTREL)                     REL
0x00000017 (JMPREL)                     0x36014
0x00000011 (REL)                        0x33f34
0x00000012 (RELSZ)                      8416 (bytes)
0x00000013 (RELENT)                     8 (bytes)
0x00000016 (TEXTREL)                    0x0
0x6ffffffa (RELCOUNT)                   1051
0x00000000 (NULL)                       0x0

Here, I find it very interesting that the library has relocation symbols that refer to 'cblas' entries, but 'libgslcblas.so.0' is not listed in the dynamic section. This feels wrong to me, but I don't have the expertise to say so definitively. Can anyone help?

I am continuing to investigate, but I would really appreciate any suggestions, corrections or input or any sort!

Questions

1. Should 'libgslcblas.so.0' be in the Dynamic section of 'libgsl.so.0' given that 'libgsl.so.0' makes references in its relocation section to cblas constructs?
2. Could the improperly set RPATH be at the root of all this?

I would suggest using the AOSP instead of autotools.

The GSL can be integrated into Android, by wrapping the GSL source code into Android make files. You can then use the modules defined in this Android make files to access the functionality of the GSL.

However this only provides access to Applications compiled in the AOSP.