I built an android application which uses the libcurlstatic.a, libssl.so,and libcrypto.so in native code and generates one more shared lib called libcurlapp.so ,, Here I would like to know that when ever I want to load this lib in my application is it necessary to load all the libraries or only libcurlapp.so will be enough ..?
Yes your Java code is responsible for loading all necessary shared libraries in the proper order.
This only involves the libs you install with your APK. The system libraries that come with the device in /system/lib will be loaded as needed by the system.
The order you load the libs is important: if libcurlapp.so makes calls to libssl.so and libcrypto.so, you should first load libssl.so and libcrypto.so.
Related
I have a libsomething.a file which is a static library with all dependencies included.
I need to be able to import this in Python as it is a Python C library. According to this, it is not possible to use a static library as a CPython library.
How can I take my .a file and make it a .so, keeping all static dependencies baked in?
Background: I am using Crowbar to build a CPython shared library which can be called from Python in AWS Lambda. Until now, it has worked flawlessly, but as soon as I added in dependencies which require OpenSSL, I get linker problems when running the code in Lambda.
The issue here is that the Amazon Linux image that is used to execute code has an ancient OpenSSL version. I have recreated the runtime environment, but the issue is that the old version of OpenSSL no longer exists in Amazon's yum repository. This means that installing openssl-devel pulls down OpenSSL 1.0.2k, where in the runtime the version of OpenSSL provided is 1.0.1.
This results in linking failing at runtime in Lambda. Therefore, I need a way to build a (mostly) statically linked shared library. The only shared libraries I want my SO to link from are libc and the kernel, with everything else statically compiled in.
In the Lambda execution environment, LD_LIBRARY_PATH is set to /usr/lib64:/lib64:./lib, so anything in the lib folder will be loaded, but only as a last result, and if I link against OpenSSL, I get the wrong version every time.
In Rust, I have the option of producing liblambda.a or liblambda.so, a static or a shared library. I'm assuming that producing a *.a and then converting into a shared library only linking to glibc and kernel dependencies.
No, you cannot do that conversion from static library to shared one (at least not in practice). Read How To Write Shared Libraries by Drepper.
One of the main reason is that shared libraries want (that it nearly need) to have position independent code (which static libraries usually don't have).
However, on Linux most libraries are free software. So why don't you recompile your library from source code into a shared library?
(you might perhaps recompile that specific version of OpenSSL from source)
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 am working on a cross platform, building on PC running on ARM.
I have several targets with different sets of shared libraries.
I am building a single executable which is linked with all the shared libraries.
I can't run it on targets that some shared libraries missing on. I get loader error.
Is there a way to 'tell' the loader to ignore the missing shared libs?
I will deal the the missing functions in run-time, I really need one executable..
No. You cannot tell the dynamic loader to ignore missing libraries.
What you can do is load the libraries dynamically using functions like dlopen and dlsym.
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.