I know how to link with a shared library, and I know if launched by java code, we can System.loadLibrary every .so. So, my question is: how to load multiple .so files with pure ndk. The value of "meta-data android:name='android.app.lib_name'" in AndroidManifest.xml only can specials one library name, how to add the other shared librarys name?
It seems Im not understanding, because if load shared library from java, we need load each shared librarys by System.loadLibrary. but from pure ndk, you can only have one entry, other shared librarys must explicit linked the entry library. so, the android system will load them automaticly.
Related
I was looking through /usr/lib/x86_64-linux-gnu and noticed that some applications, such as gedit, ship with shared object files. I understand why libraries ship with shared libs, but what advantage is there for a stand-alone application to do the same?
Looking at the gedit example, it comes with following shared libraries:
/usr/lib64/gedit/libgedit.so
/usr/lib64/gedit/plugins/libdocinfo.so
/usr/lib64/gedit/plugins/libfilebrowser.so
/usr/lib64/gedit/plugins/libmodelines.so
/usr/lib64/gedit/plugins/libsort.so
/usr/lib64/gedit/plugins/libspell.so
/usr/lib64/gedit/plugins/libtime.so
The first one, libgedit.so, is for other applications that can reuse the editor component of gedit.
The rest of them are plugins for gedit. While they are built and distributed together with the application, they are independent addons and gedit should work without them too. 3rd party plugins could be there as well.
If someone want to write plugins for these application they can use a provided API which is usable by the shared libraries.
Also when you have multiple executables using the library in one software-package you can reduce the size of those binaries by shipping also a shared library instead of linking it staticly into each binary.
I am working on bindings for a cpp library.
To do this I wrote a capi / wrapper for the library and compiled that to a shared lib (.so file).
My question is, how do I then use and integrate this file into cargo without forcing the user to install it? Currently I build the cpp via a Makefile called from the build variable in Cargo.toml, but I am unsure what to do with the compiled lib.
For testing, I can either use rpath or LD_LIBRARY_PATH to point the executable to the right location, but this will not work when distributing a library.
How are people managing this?
First of all, determine whether you really need a shared library. It's not clear from your question, but if you compiled your own wrapper into a shared library, that's probably unnecessary - you can compile your code into a static library and link it directly into your executable.
Moreover, you can try to link that third-party library statically too. I don't think this should be hard. And yes, you need to use build command in the manifest to do all of this now.
However, if you still need to use a shared library and you don't want the end user to install it herself (which is strange, because that's the point of shared libraries), you have to distribute it manually. For example, you can write a makefile which assembles an archive which your users may extract and use. For your program to find the library correctly you will either have the user to install this archive into the system root directory (e.g. /usr on linux; then this shared library will be located automatically) or you will have to write small shell script wrapper around your executable which will locate the shared library and set appropriate LD_LIBRARY_PATH.
I'd go for the first path. Usually all major platforms provide means to create installation packages (deb/rpm/pkg.tar.xz/whatever on Linux, brew on Mac, windows installer on Windows, though on Windows you can just put your shared library in the same directory as the executable and it will work). You just have to create packages for the platform your users work on, so your program will be installed in correct directories and your shared library will be resolved automatically.
I need to call a function which belongs to a native Android code written in C . i just need one function and the native code is huge. What would be the way to achieve this in best possible way?
Do you mind to disclose the name of the function? I am asking because native non-documented APIs in Android can be crudely divided into three categories: code that is ODM dependent, code that is relatively stable, and code that is unstable or not exported by system libraries.
Regarding the first, you have no choice but to use the device-specific library. Usually, you can download such library from one device, and, not without great care, your library that dynamically links to that system lib, may work on other devices. Typical example is the OpenMAX family of libraries (see for example Creating Android app using OpenMAX library in GB, but showing not found?).
Regarding the second, the purists will download parts of the source tree and compile them into their local shared lib, but the practice of reusing a system lib is widespread (see for example shared memory in android ndk).
For the third, you have no choice but to recompile the AOSP code yourself.
Is it possible to stick a shared library to an app? I don't want to cross compile or anything like that. the shared library uses typical libraries which are available on target systems( i.e. Ubuntu 32bit x86) according to 'ldd'.
If there is a staticly built version of the library available (libxxx.a instead of libxxx.so), the easiest way would be to link against that. If that is not possible, you could create something like a self-extracting executable tar file with the app and the shared library. For example, see http://www.linuxjournal.com/content/add-binary-payload-your-shell-scripts
I have read that .so is a dynamic library file and .a is a static library file.
While building openssl i gave the option ./Configure no-shared and it created a lot of .a files.
So, my question is will the other packages like apache will be able to use .a files from openssl?
for example libcrypto.a,
someone please advice me if im going enirely through wrong path.
Basically the static library can be compiled into another application at link time. In your example Apache could use libcrypto.a during build time and include it in the Apache httpd application.
A dynamic .so library can be loaded and unloaded at runtime and you have a better flexibility to change what Apache should support without recompiling the Apache binaries.
Using Apache as example the dynamic loading of .so files are described in the Dynamic Shared Object (DSO) section in the documentation. You can also find links to the installation section which describe how to include static libraries at build time.
There is a good question about this that could be good to read, and that provide mote details in the subject.
Difference between shared objects (.so), static libraries (.a), and DLL's (.so)?
If A.a is static library and two different programs want to use it. A.a is created two times for each program. while If A.so is dynamic library than two programs access same file.
Its mean that you are using reference in library.
If your library is going to be shared among several executables(like apache and openssl), it often makes sense to make it dynamic to reduce the size of the executables. Otherwise, definitely make it static.
In your case you must create dynamic library
Please read -
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html.
It is a very good tutorial with example.
you will learn -
what is static library (.a) and how to make it.
what is shared library (.so) and how to make it.
difference with .ddl (windows os)