I have an android .so(example.so) file which is build with some n number of static libraries(.a files). Is there is any way to find what are the static libraries used to built that .so(example.so) file.
It's not possible to figure out which static libraries were used to build the shared library. Shared libraries aren't a container of their components like static libraries are, but are a linked form of all the object files.
I think the best you can do here is figure out which source files are included, and only if the library hasn't been stripped. You can use readelf -sW libfoo.so, and if it was built from foo.cpp you'll see:
...
18: 00000000 0 FILE LOCAL DEFAULT ABS foo.cpp
...
Some linux apps like supertuxkart or regnum online have static binaries, which after downloading just work without needing to install any shared library. On every distro. How can I make such an app?
Ensure that all your resources are contained in the executable and link the executable statically:
gcc -o foo main.o -static -lbaz -lbar
However, this also has drawbacks. Look up dynamic linking.
When using the -Wl--whole-archive ... -Wl--no-whole-archive flags with gcc how is it that you veryify that everything links correctlly internal to the library? Also how do you verify that the library can call into other Dynamic libries that are specifed by LD_LIBRARY_PATH or ld(1)?
Assuming you want to build a shared library one solution would be to link a minimal executable against that library as part of you build and see if you get unresolved symbols. Of course this file wouldn't be installed.
The executable you build can really be minimal, for my C++ code I usually use
int main() { }
I am using autoconf gnu tools to build my product.
It generates both the shared as well as static library for any library where *.la is mentioned.
The issue is if you use .la to link your binary in Makefile.am.
It links with the dynamic library but when you use ldd to the binary, it says
"not a dynamic executable" although it links with shared library. I proved it by removing the shared library after the binary is built and then tried to run the binary. It didn't find the shared library and couldn't run.
Another question is how to put library in a specified location using Makefile.am direction ?
Looks like you run ldd on the wrapper scripts created by libtool. They are used to link uninstalled libraries with uninstalled executables. Real binaries are placed in .libs directory.
You can install a lib to some specific place in this way
mylibrary_LTLIBRARIES = libmylibrary.la
mylibrarydir = ${libdir}/my_plugins/
How can I link a shared library function statically in gcc?
Refer to:
http://www.linuxquestions.org/questions/linux-newbie-8/forcing-static-linking-of-shared-libraries-696714/
You need the static version of the library to link it.
A shared library is actually an executable in a special format
with entry points specified (and some sticky addressing issues
included). It does not have all the information needed to
link statically.
You can't statically link a shared library (or dynamically link a static one).
The flag -static will force the linker to use static libraries (.a) instead of shared (.so) ones. But static libraries aren't always installed by default, so you may have to install the static library yourself.
Another possible approach is to use statifier or Ermine. Both tools take as input a dynamically linked executable and as output create a self-contained executable with all shared libraries embedded.
If you want to link, say, libapplejuice statically, but not, say, liborangejuice, you can link like this:
gcc object1.o object2.o -Wl,-Bstatic -lapplejuice -Wl,-Bdynamic -lorangejuice -o binary
There's a caveat -- if liborangejuice uses libapplejuice, then libapplejuice will be dynamically linked too.
You'll have to link liborangejuice statically alongside with libapplejuice to get libapplejuice static.
And don't forget to keep -Wl,-Bdynamic else you'll end up linking everything static, including libc (which isn't a good thing to do).
Yeah, I know this is an 8 year-old question, but I was told that it was possible to statically link against a shared-object library and this was literally the top hit when I searched for more information about it.
To actually demonstrate that statically linking a shared-object library is not possible with ld (gcc's linker) -- as opposed to just a bunch of people insisting that it's not possible -- use the following gcc command:
gcc -o executablename objectname.o -Wl,-Bstatic -l:libnamespec.so
(Of course you'll have to compile objectname.o from sourcename.c, and you should probably make up your own shared-object library as well. If you do, use -Wl,--library-path,. so that ld can find your library in the local directory.)
The actual error you receive is:
/usr/bin/ld: attempted static link of dynamic object `libnamespec.so'
collect2: error: ld returned 1 exit status
Hope that helps.
If you have the .a file of your shared library (.so) you can simply include it with its full path as if it was an object file, like this:
This generates main.o by just compiling:
gcc -c main.c
This links that object file with the corresponding static library and creates the executable (named "main"):
gcc main.o mylibrary.a -o main
Or in a single command:
gcc main.c mylibrary.a -o main
It could also be an absolute or relative path:
gcc main.c /usr/local/mylibs/mylibrary.a -o main
A bit late but ... I found a link that I saved a couple of years ago and I thought it might be useful for you guys:
CDE: Automatically create portable Linux applications
http://www.pgbovine.net/cde.html
Just download the program
Execute the binary passing as a argument the name of the binary you want make portable, for example: nmap
./cde_2011-08-15_64bit nmap
The program will read all of libs linked to nmap and its dependencias and it will save all of them in a folder called cde-package/ (in the same directory that you are).
Finally, you can compress the folder and deploy the portable binary in whatever system.
Remember, to launch the portable program you have to exec the binary located in cde-package/nmap.cde
Best regards
In gcc, this isn't supported. In fact, this isn't supported in any existing compiler/linker i'm aware of.