Shared library symbols not visible on dlopen()?
fornwall opened this issue · 3 comments
I have a shared library libshared.so containing a function libshared_get_value().
I also have a shared library libplugin.so, which does not link against libshared.so but references the extern function libshared_get_value()
Finally there is an executable linking against libshared.so. At runtime this executable tries to dlopen() the libplugin.so shared library.
This works on "normal" Linux (tested on Ubuntu 16.04).
This does not work on Android (tested on Android 5.0/arm and 6.0/aarch) but fails at runtime with the error message cannot locate symbol "libshared_get_value" referenced by "libplugin.so".
This difference in behaviour causes problems for things like perl and node, where extensions built as shared libraries expects symbols from already loaded libraries to be visible without needing to link against the libraries containing the symbols explicitly. See e.g. How To Link -lperl to Extensions During Build where the following is said:
Thanks to its broken linker, I need to link libperl.so with every extension that uses symbols from it.
Is the Android linker (or tools) really broken in this regard, or is the behaviour the expected/desired one?
See https://github.com/termux/shared-library-testcase for a small test case.
tl;dr; This one of the not many differences between linux loader and android loader. On Android only the main executable and LD_PRELOADs are considered to be RTLD_GLOBAL, all the dependencies of the main executable remain RTLD_LOCAL.
Longer explanation:
ld-linux.so marks everything linked against main executable with RTLD_GLOBAL, this is why the example works on Linux. Android loader was not handling RTLD_GLOBAL correctly up until M release. It was fixed in M for things like dlopen/dlsym() but not for the dependencies of the main executable, because it lead to many compatibility problems.
Workaround:
Adding libshared.so dependency to libplugin.so should solve this problem and make the executable.
@dimitry- Thanks a lot for the information!
I guess this issue can be closed here as it's not an NDK issue.
I get some error