Android linker issue with external symbols #4
Description
I'm not sure yet why this problem occurs, but for native applications (not libraries) the android runtime linker doesn't hook up the symbols correctly. We currently use a workaround (using dlsym in dmain2.d) to fix stdout, stdin, stderr, but there may be more symbols affected. We should try to find a proper fix (although, officially the NDK doesn't support standalone applications, so we may be out of luck here).
More information:
As of Android 1.0, this scheme does not seem to work. Below is what I have learned recently.
Try changing "printf(..." to "fprintf(stdout, ...)" in motz's example, and you'll probably get nothing. This is because, under Android,
the way an executable is linked to shared libraries is non-standard (or at least different from the popular glibc way). With the
conventional way presented by motz, the linker (ld) allocates the executable's own copies of the library global variables such
as stdin/stdout/stderr (__sF), environ, optind, etc. parallel to and unshared with the libraries.
To make an executable compatible with Android's libc (bionic), one has to force the compiler to include a few Android's special
include files at the compile time and do a few other tricks at the link time. But the easiest way is to use Android's build macrons
found in Android.mk's.
Overall, it's possible to drop in external executable and library modules to Android, but it's not trivial unless the Makefiles strictly
follow Android's proprietary convention.
(from http://honeypod.blogspot.de/2007/12/dynamically-linked-hello-world-for.html)