Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Android linker issue with external symbols #4

Open
jpf91 opened this Issue Mar 22, 2012 · 0 comments

Comments

Projects
None yet
1 participant
Owner

jpf91 commented Mar 22, 2012

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment