Bero,
On 26/04/13 22:17, Bernhard Rosenkränzer wrote:
Hi, I'm running into an interesting problem with driver blobs when building Android with the 4.8 toolchain:
E/libEGL ( 1219): load_driver(/vendor/lib/egl/libEGL_POWERVR_SGX540_120.so): Cannot load library: soinfo_link_image(linker.cpp:1635): could not load library "libIMGegl.so" needed by "libEGL_POWERVR_SGX540_120.so"; caused by soinfo_link_image(linker.cpp:1635): could not load library "libsrv_um.so" needed by "libIMGegl.so"; caused by soinfo_relocate(linker.cpp:975): cannot locate symbol "__aeabi_uidiv" referenced by "libsrv_um.so"...
__aeabi_uidiv is a libgcc.a function (Android doesn't have libgcc_s) - and the blob makers didn't link libgcc.a properly, so it is understandable why this would be missing.
However, Android's libc has an ugly but (up until now) working workaround that is supposed to address this sort of issue.
So technically if you don't provide these functions somewhere in your toolchain you aren't ABI compliant. And this hack looks odd.
It includes libgcc_compat.c, which comes down to
#define COMPAT_FUNCTIONS_LIST \ XX(__aeabi_uidiv) \ ... (same for other libgcc functions) #define XX(f) extern void f(void); COMPAT_FUNCTIONS_LIST #undef XX void __bionic_libgcc_compat_hooks(void) { #define XX(f) f(); COMPAT_FUNCTIONS_LIST #undef XX }
Running nm on libc.so shows the symbol is actually in libc.so, and it seems to be visible.
$ nm /system/lib/libc.so |grep aeabi_uidiv 0004f5d8 t __aeabi_uidiv 0004f680 t __aeabi_uidivmod
libsrv_um.so is linked to libc too, so it should see it...
$ objdump -x /vendor/lib/libsrv_um.so |grep libc.so NEEDED libc.so
Can anyone think of a reason why this would work fine if the system is built with the 4.7 toolchain, but break with 4.8?
My first thought was that 4.8 might have miscompiled the dynamic linker - but the problem remains if I copy in /system/bin/linker from the 4.7 build.
Has the symbol visibility of __aeabi_uidiv changed?
What are you building for? Cortex-A15 and -A7 have divide instructions, so you might have issues there.
It might also be worth seeing what libgcc_s looks like in 4.7 and 4.8 and see what has changed about the objects there.
Thanks,
Matt