Can shared library call another shared library?
ls02
library? Both shared libraries are our own and presumed to be
installed together with the app into the same folder.
Any examples of how to do this?
Onur Cinar
Hi,
As far as I recall, that used to work for us, when we did System.loadLibrary for each of them in the Java layer. Never tried it with the latest OS versions, but If I can find that code, I'll post it.
Regards,
-onur
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
---
www.zdo.com
Angus Lees
> Can one shared library load and call functions from another shared
> library? Both shared libraries are our own and presumed to be
> installed together with the app into the same folder.
Yes, it works in a reasonably straightforward linux/unix way, with
some important bugs that you will need to know how to work around.
There are two approaches depending on what you need:
- If you always want both libraries then you can just dynamically link
the second to the first libary.
Basically you just add "-lsecond" to the link command of the first
library. The Android run-time linker will then load up the second
library whenever the first is loaded, resolve the symbols in the
second library, and everything will work, just like calls into libc.so
or some other standard shared library.
Important bug: Android doesn't add the app-specific library directory
to the linker search path, so you can't "just" do the above. The
workaround is to manually load up your libraries in reverse order from
Java first, then the run-time linker will discover the already loaded
library and resolve symbols correctly. Also, the java
System.loadLibrary() function *does* look in the app-specific
directory so you don't need to fully-qualify your path names at that
point.
- If you want to dynamically or conditionally load additional
libraries (aka "plugins" or "modules" in this case) then you need to
use dlopen().
dlopen(), dlsym(), etc are the C functions you want here. Do a Google
search and you'll find plenty of manpages and examples of how to use
these.
Common mistake: make sure the symbols you are trying to load aren't
C++ symbols, or they get mangled by the compiler. You wan't 'extern
"C" void myfunction() { ... }' to tell the C++ compiler to leave
'myfunction' unmangled.
Important bug: Android versions before 2.0 behaved as if you always
used dlopen(RTLD_GLOBAL); Android 2.0 and later behave as if you
always use dlopen(RTLD_LOCAL). This latter means that any library
you load won't be able to use symbols back in your existing program
unless you explicitly link the plugin libraries to the first at
compile time (basically taking advantage of the above situation).
> Any examples of how to do this?
The Android ScummVM port does the latter a lot, although the example
might be a bit complicated to follow since the plugin libraries get
shipped in separate Android apks. I'm happy to expand on any of the
above if you need more information.
- Gus
ls02
calling LoadLbrary from the shared library itself followed by
GetProcdress for each exported API I want to call.
On Oct 14, 7:17 pm, Angus Lees <g...@inodes.org> wrote:
Angus Lees
> I want to avoid any static linking. In Windows world this would mean
> calling LoadLbrary from the shared library itself followed by
> GetProcdress for each exported API I want to call.
Why do you want to avoid static linking? It is certainly the much
easier approach on Android.
dlopen(), dlsym() are the Unix equivalents of LoadLibrary,
GetProcaddress (ie: the second approach that I mentioned). If you
want to use the same library every time then using the usual dynamic
linker is easier (first approach) since you don't need to do anything
in your code beyond just invoking the function. In other words, I
still don't know enough about your situation to recommend a particular
approach ;)
- Gus
Russell Tillitt
If the library involved is used by many clients, likely to be cached,
and/or it is used only conditionally -- ie, you genuinely need it to be
"dynamic" -- then dynamically link.
Otherwise, if it is a dedicated library that is virtually always needed
by your code, statically linking is the often better approach: 1.)
smaller footprint (deadstripping); 2.) faster load-time; 3.) easier to
deploy & maintain.
rt
--
Russell Tillitt
CEO & Co-Founder
Embee Mobile, Inc
Facebook: http://apps.facebook.com/mobilewallet
Website: http://www.embeemobile.com
ls02
installed on some devices and the code in the main shared library must
be able to work with and without it. So static linking cannot be used.
The loaded library is used only by the library that loads it.
Sorry I am not proficcient in Linux yet. Windows has delay-loading
when the DLL is loaded dynamically on the first acess to the exported
API. The linker essentually injects LoadLibrary/GetProcAddress code
into executable, however if the DLL or exported API is not found an
exception is thrown. I don't know how it is done on Linux, I assume
"dynamic loading" you mention is similar to Windows delay loading. If
dynamic loading is implicit on first call to exported API what happens
if the library cannot be found or loaded or the API does not exist?
On Oct 14, 9:05 pm, Angus Lees <g...@inodes.org> wrote:
>
> - Show quoted text -
Christian Linne
(Shortened: You have evaluate what the functions return, but that's similar on Windows, as far as I know).
The optional shared library I need to load dynamically may not be
installed on some devices [...]
--
_________
Mit freundlichen Grüßen
Yours sincerely
Christian Linne
Mail (private): linn...@aol.com
Mail (official): Christi...@googlemail.com,
ICQ: 293253013
Angus Lees
The optional shared library I need to load dynamically may not be
installed on some devices and the code in the main shared library must
be able to work with and without it. So static linking cannot be used.
The loaded library is used only by the library that loads it.
ls02
library itself?
On Oct 15, 10:20 am, Angus Lees <g...@inodes.org> wrote:
Nasif Noorudeen
ls02
shared library in the same path. What I need though is to get this
path from the calling library.
> > .
Angus Lees
> Is there way to get the path of the shared library file from the
> library itself?
Not that I know of. Easiest is to find the library path using various
Java functions and then pass that down to your native code.
ScummVM is probably not a good example to follow here: I unpack the
extra shared libraries myself to avoid some other Android package
installer bugs, so I always know exactly where the additional
libraries are.
- Gus
> On Oct 15, 10:20 am, Angus Lees <g...@inodes.org> wrote:
>> On Fri, Oct 15, 2010 at 20:52, ls02 <agal...@audible.com> wrote:
>> > The optional shared library I need to load dynamically may not be
>> > installed on some devices and the code in the main shared library must
>> > be able to work with and without it. So static linking cannot be used.
>> > The loaded library is used only by the library that loads it.
>>
>> Right - you'll need dlopen() for this. It is pretty easy to use - look for
>> any Unix/Linux example on the internet.
>> If this library properly declares all its dependent libraries then it should
>> just work.
>>
>> - Gus
>
ls02
what Android bugs are you talking about?
On Oct 17, 8:18 am, Angus Lees <g...@inodes.org> wrote:
Chris Stratton
> Is there way to get the path of the shared library file from the
> library itself?
in /proc/self/maps from any part of the same process