I am converting a set of static libraries to shared libraries and was able to create the shared libraries successfully. The problem is with the exe's because linking with static library can have unresolved symbols in the library but that is not the case with shared libraries. All the symbols in the shared library should get resolved.
Example:
PROG1 calls LIB1.a calls LIB2.a
Now the make file of PROG1 need not have LIB2.a as PROG1 calls to LIB1.a do not result in calling LIB2.a .So some LIB2.a symbols in LIB1.a can remain unresolved.
After conversion
Both LIB1.so and LIB2.so have to be included in the makefile of PROG1. Including LIB2.so resolves few linkage issues of LIB1.so but new issues appear due to inclusion of LIB2.so(as it may be depend on LIB3.so)
SO is there any way to find out the all the dependent libraries of a shared library?
I tried using ldd but it prints nothing.
Please let me know if my analysis is wrong.
This is a slightly personal opinion, but I think you should link your shared libraries so that you get an error for unresolved symbols (with -z defs). That means you sort out each library independently and don't get any nasty surprises at link time.
Of course, this only works if your libraries are clean and don't contain recursive dependencies (which are probably a bad thing anyway) and you aren't trying to do dynamic loading where you can load any of impl_1.so, impl_2.so or impl3_.so to provide code for a client client.so at runtime. But it works well if all you have are link time dependencies.
Indeed, if you don't do this, and are using ld rather than cc to do the linking,, you'll get pretty much what you're seeing - no dependencies, and errors at linktime
Related
I don't understand the difference between the two types of libraries, and many websites say that they are the same thing, but at school we use two different commands to create them
dynamic library
$ gcc -shared -o libsample.so lib.c
$ gcc -o main main.c -ldl
to execute:
$ ./main ./libsample.so
shared library
$ gcc -shared -o libsample.so lib.c
$ gcc -o main main.c -L. -lsample
to execute:
$ LD_LIBRARY_PATH=. ./main
Can someone help me in understanding the difference between the two "codes"?
Dynamic Linked Library (.DLL) is the terminology used by Microsoft Windows. Shared Object (.so) is the terminology used by Unix and Linux.
Other than that, conceptually they're the same.
Regarding your snippets of commands, I guess the difference (and I'm only guessing here, because you didn't show us the relevant parts) is how the library is loaded. There is "link time loading" where the library is tied to the executable by the linker¹. And there is "runtime loading", where the program sort of "ingests" the dynamic/shared library.
runtime loading is done in Windows with the LoadLibrary (there's an …A and a …W variant) function, and on Unix/Linux with dlopen (which is made available by libdl which is linked to by that -ldl library link statement).
1: The linker is the program that creates the actually executable file from the intermediary objects created by the various compiler stages.
Dynamic and shared libraries are usually the same. But in your case, it looks as if you are doing something special.
In the shared library case, you specify the shared library at compile-time. When the app is started, the operating system will load the shared library before the application starts.
In the dynamic libary case, the library is not specified at compile-time, so it's not loaded by the operating system. Instead, your application will contain some code to load the library.
The first case is the normal case. The second case is a special use and it's mainly relevant if your application support extensions such a plug-ins. The dynamic loading is required because there can be many plug-ins and they are built after your application. So their names are not available at compile-time.
I am trying to create .so dynamic library from *.o files and facing below issue.
LOG:
[nptemp-static]$ gcc -shared *.o -o libexample.so
/usr/bin/ld: bindings_hubbub_parser.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
bindings_hubbub_parser.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
Any idea? Do I need to recompile my whole source code with the option specified?
Actually, I am not aware of the source code which I compiled because all the source code is open source which I downloaded and compiled by following instructions in README.
I am trying to create .so dynamic library from *.o files and facing below issue.
This is not that simple. In practice, you should compile specifically when making a shared library, at least on Linux.
(Perhaps you might need to edit your Makefile or configure somehow your build automation if it was not designed for building a shared library; if building some free software library, you might ask help from its authors or community)
Shared libraries want to have position independent code. So you need to compile their source code with the -fPIC flag passed to g++ or gcc (see this). You could also want to explicit the rpath.
Read Drepper's paper: How To Write Shared Libraries.
TL;DR - I need to compile archive.a with test.o to make an executable.
Background - I am trying to call a function in a separate library from a software package I am modifying but the function (a string parser) is creating a segmentation violation. The failure is definitely happening in the library and the developer has asked for a test case where the error occurs. Rather than having him try to compile the rather large software package that I'm working on I'd rather just send him a simple program that calls the appropriate function (hopefully dying at the same place). His library makes use of several system libraries as well (lapack, cblas, etc.) so the linking needs to hit everything I think.
I can link to the .o files that are created when I make his library but of course they don't link to the appropriate system libraries.
This seems like it should be straight forward, but it's got me all flummoxed.
The .a extension indicates that it is a static library. So in order to link against it you can use the switches for the linking stage:
gcc -o myprog -L<path to your library> main.o ... -larchive
Generally you use -L to add the path where libraries are stored (unless it is in the current directory) and you use -l<libname> to sepecify a library. The libraryname is without extension. If the library is named libarchive.a you would still give -larchive.
If you want to specify the full name of the library, then you would use i.e. -l:libname.a
update
If the libraypath is /usr/lib/libmylibrary.a you would use
-L/usr/lib -lmylibrary
I'm trying to create a static library to use inside my PHP extension. To do that, I'm compiling my .c files using gcc -c file.c -o file.o and obtaining .o files. I then use ar rcs lib.a *.o to archive all the compiled objects into an .a file.
After doing this, I'm referring to this .a file when compiling my PHP extension, but I get the following error:
*** Warning: Linking the shared library <extension>.la against the
*** static library lib.a is not portable!
If I use the .o files instead of the .a file, I get:
*** Warning: Linking the shared library <extension>.la against the non-libtool
*** objects file1.o file2.o is not portable!
What am I doing wrong and what's the correct way of doing this?
The short answer: shared libraries (of which a PHP extension is a special case) cannot depend on static libraries.
Actually that's not quite entirely true. As long as your static library is built as position-independent code (PIC), using it from a shared library will work; whatever .o files from the archive are needed to satisfy the undefined symbols in the .o files you explicitly linked to make the .so will get pulled in and become part of the shared library file.
Linking non-PIC .o files into a shared library will also work on some archs (like i386) but it's not portable (and won't work on x86_64).
As for what you should do, if it's possible, I would just forget about the intermediate .a file and link all your .o files explicitly into the .so file for the extension. This is clean and simple. Or you could keep doing it the way you're doing as long as you're sure all your files got built as PIC (i.e. with the -fPIC option).
What I would not do is make and install an extra .so file that the main .so file for the extension will then depend on. All this does is create bloat, increase load time, and make lots of trouble with deployment/integration.
Linking shared libraries to static libraries is not possible (unless you really know very well what you are doing). Don't do it.
The first warning is from libtool. It tells you, that the operation you asked for will do different things on different systems and some of those things are probably not what you want. Often it's just going to fail in various spectacular ways, because code that goes in shared and static libraries needs to be compiled with different compiler flags.
i have faced same problem once but i have solved it by corrcting some linking flag in make file you can see
What is the meaning of “Warning: Linking the shared library against static library is not portable”?
Let's say I have a source file, say helper.c, which gets compiled into an object library (helper.a). Now, this uses functionality from many system libraries, so currently when I want to link helper.a into an executable, I end up having to list all the dependencies:
gcc main.c helper.a -o my_app -lrt -lpthreads ...
What's the common approach to avoiding this tedium and maintenance issue? Is there some way of embedding information about the dependencies into the library so GCC can find them at link time? Or does one have to statically link the dependency libraries into helper.a?
Some compilers can generate a text file containing all the dependencies of the file being compiled. Check your compiler's documentation.
Include this text file into your makefile to resolve the dependencies.