error loading dynlib with ldopen() -- no symbol name?

Question

I'm trying to port a CLI app to Android. This app depends on several dynlibs which we already ported, but haven't tested yet. We built an .apk that provides an simple app, the libs and the executable. The app opens the .apk, extracts the libs and the executable and that's it. We took all this ideas from the Mono port to Android[3]. We also copied their way to run such an app: as the linker only loads libs from /lib (which doesn't exist) and /system/lib (which is in a read-only partition), we have to ldopen() the dynlibs by hand. This works if we compile the libs and app for Linux.

Under the Android cupcake emulator we get this error:

bionic/linker/linker.c:1126| ERROR:  2112 cannot locate '(null)'...
bionic/linker/linker.c:1641| ERROR: failed to link /data/data/fr.inria.hop/lib/libbigloogc-3.3b.so

All of this, of course, has been compiled with the compilers that are provided with Android's source code[1][3], so the resulting libs should be correct. Given the nature of the dynlibs we cannot use (yet?) the NDK infrastructure to compile dynlibs and executables[2], so we had to rely on this wrapper.

As for the error above, I found in vprintf()'s code that that's the way to represent string parameters whose pointer is actually NULL. This means that there is at least one symbol whose name is not even an empty string, so I guess somehow the dynlib is not correct.

The question, then, is: what tools can I use to debug such a situation, short of trying to recompile the linker with the debug flags enabled (bionic/linker/linker_debug.h) or try to understand the linker's code, analyze the .so file and figure it out? It would be great to at least have precompiled versions with debug enabled...

---

[1] I know that I could use the compilers provided in the NDK, but so far we wanted to stick to the whole source code. See next footnote.

[2] most of the source code is actually Scheme code which is given to a compiler that translates it to C and uses a C compiler to produce the final dynlib or executable.

[3] I cannot post more that 1 link, so if you want the links just ask for them.

Answer 1

Yes, I'm answering myself because I just found out what's going on. It's a bug in cupcake's linker. The variable sym_name is the one used to report the error 7 lines below, but is never set to the name of the symbol whose lookup failed (or to anything at all besides that NULL). This has been fixed (at least) in eclair (Android 2.0). Once I run my code on it I found what symbol was, yes, missing in my dynlib, fixed it, and now I'm a little bit less grumpy about the platform.