交叉编译GSL为Android [英] Cross Compiling GSL for Android
问题描述
交叉编译GSL Android版
我试图越过使用自动工具编译GNU科学图书馆（GSL）为Android 4.1。我的build和host如下：
构建=I386-苹果darwin10.8.0
主机=臂Linux的androideabi
自动工具的版本：
GNU Automake的版本1.11.3
GNU Autoconf的版本2.68
GNU Libtool程序版本2.4.2
我的目标是编译，我可以从外壳的模拟设备上运行的可执行文件。到目前为止，我一直在使用，我用生成的Android原生开发套件（NDK）工具链编译GSL和我的可执行文件。然后我推共享库libgsl.so.0'和'libgslcblas.so.0'（这两者都在我的可执行文件的动态部分列出）到'/系统/ lib中'和可执行到设备。
下面是输出臂Linux的androideabi-readelf -d issm.exe
偏移0x26a2a4动态部分包含26项：
标记类型名称/值
00000001（需要）共享库：[libgsl.so.0]
00000001（需要）共享库：[libgslcblas.so.0]
00000001（需要）共享库：[libm.so]
00000001（需要）共享库：[libc.so]
00000001（需要）共享库：[libdl.so]
0x0000000f（RPATH）库rpath的：[/用户/ gperez / ISSM / ISSM-UCI /干线喷气推进实验室/ externalpackages / GSL /安装/ lib目录]
0x00000020（preINIT_ARRAY）0x26d000
0x00000021（preINIT_ARRAYSZ），位于0x8
0x00000019（INIT_ARRAY）0x26d008
0x0000001b（INIT_ARRAYSZ）1100（字节）
0x0000001a（FINI_ARRAY）0x26d454
0x0000001c（FINI_ARRAYSZ）8（字节）
0x00000004（HASH）0x8128
0x00000005（STRTAB）0x96a0
0x00000006（SYMTAB）0x87f0
0X0000000A（STRSZ）3588（字节）
0x0000000b（SYMENT）16（字节）
0x00000015（调试）为0x0
0x00000003（PLTGOT）0x27239c
0x00000002（PLTRELSZ）960（字节）
0x00000014（PLTREL）REL
0x00000017（JM preL）0xa7ec
0x00000011（REL）0xa4a4
0x00000012（RELSZ）840（字节）
0x00000013（松口）8（字节）
00000000（NULL）为0x0
我意识到RPATH是不正确的，但如果我理解正确的动态链接器，那么它应该无法找到RPATH需要的库，然后进行检查LD_LIBRARY_PATH，所有的库都位于
我随后开始运行我的可执行文件，但我很惊讶地发现以下链接错误：
link_image [1936年]：468无法加载所需库libgsl.so.0'为'./issm.exe（reloc_library [1285] 468找不到'cblas_ctrmv ...
）不能链接EXECUTABLE
此错误导致我检查'libgsl.so.0的它们的内容如下：
搬迁节.rel.plt偏移0x36014包含161项：
偏移信息类型Sym.Value符号。名称
00201c54 00002316 00000000 R_ARM_JUMP_SLOT cblas_ctrmv
00201c58 00002f16 R_ARM_JUMP_SLOT 00000000 cblas_zswap
00201c5c 00003816 00000000 R_ARM_JUMP_SLOT cblas_zsymm
00201c60 00005016 00000000 R_ARM_JUMP_SLOT cblas_cgeru
00201c64 00009216 00000000 R_ARM_JUMP_SLOT cblas_sgemm
00201c68 00009c16 R_ARM_JUMP_SLOT 00000000 cblas_ctrsv
00201c6c 0000c316 R_ARM_JUMP_SLOT 00000000 cblas_sgemv
...
的'libgslcblas.so.0相应的显.dynsym
符号表'显.dynsym包含233项：
编号：值大小类型绑定可见NDX名称
...
218：0004e148 64 FUNC全局默认7 __aeabi_f2d
219：00050314 0 NoType在全局默认12 __data_start
220：0000d69c 1604 FUNC全局默认7 cblas_dgbmv
221：0002e008 3540 FUNC全局默认7 cblas_ctrmv
222：00042c34 4184 FUNC全局默认7 cblas_ztbmv
223：688 0004de4c FUNC全局默认7 __subdf3
224：284 00003dc4 FUNC全局默认7 cblas_snrm2
...
由于在搬迁节.rel.plet的第一项会导致连接失败，问题很可能是与所有cblas符号。然后，我决定看看libgsl.so.0
的动态部分 动态部分偏移0x200b60包含25个条目：
标记类型名称/值
00000001（需要）共享库：[libm.so]
00000001（需要）共享库：[libc.so]
00000001（需要）共享库：[libdl.so]
0x0000000e（SONAME）库的soname：[libgsl.so.0]
0x00000010（符号）为0x0
0x0000000f（RPATH）库rpath的：[：/用户/ gperez / ISSM / ISSM-UCI /干线喷气推进实验室/ externalpackages / GSL /安装/ lib目录]
0x00000019（INIT_ARRAY）0x200c68
0x0000001b（INIT_ARRAYSZ）8（字节）
0x0000001a（FINI_ARRAY）0x200c70
0x0000001c（FINI_ARRAYSZ）12（字节）
0x00000004（HASH）0xb4
0x00000005（STRTAB）0x19b1c
0x00000006（SYMTAB）0x860c
0X0000000A（STRSZ）107542（字节）
0x0000000b（SYMENT）16（字节）
0x00000003（PLTGOT）0x201c48
0x00000002（PLTRELSZ）1288（字节）
0x00000014（PLTREL）REL
0x00000017（JM preL）0x36014
0x00000011（REL）0x33f34
0x00000012（RELSZ）8416（字节）
0x00000013（松口）8（字节）
0x00000016（TEXTREL）为0x0
0x6ffffffa（RELCOUNT）1051
00000000（NULL）为0x0
在这里，我觉得很有趣的是，库中有引用cblas条目搬迁符号，但是libgslcblas.so.0'没有在动态部分列出。这种感觉我错了，但我不具备专业知识，这样肯定地说。谁能帮助？
我继续调查，但我真的AP preciate任何建议，更正或输入或任何形式的！
问题
- 如果'libgslcblas.so.0'是的'libgsl.so.0动态部分因为libgsl.so.0使得其搬迁部分引用cblas结构？
- 能否设置不当RPATH是在这一切的根源在哪里？
我会建议使用，而不是自动工具的AOSP。
在GSL可以集成到Android上，通过包装GSL源$ C $ C到Android的make文件。
然后，您可以使用此定义模块的Android make文件访问GSL的功能。
然而，这只能访问在AOSP编译的应用程序。
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
- 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?
- 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.
这篇关于交叉编译GSL为Android的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
