Is it possible to convert a shared library (someLib.so) to a static library? (someLib.a)
No. (At least for ELF shared library). A shared library is a simple object (so stands for shared object). A static library is a collection of objects. In the process of building the shared library you combine several objects and you lose some of the information which would be needed to retrieve them.
YES if you have the source code of the shared library.
NO if you don't have the source code of the shared library.
Related
I developed a C++ modular program which loads its modules dynamically. Each module needs a specific static library and I linked this static library to each module. Is there any way to share this static library among all modules without linking it to them separately?
Yes, it is possible. Instead of static library, create dynamic library (so on *nix or dll on Windows) and link your modules against this dynamic lib.
I am writing a build system for a project and I am not sure about the links between executables, static libraries and shared libraries.
For me there are three affirmations:
An executable can use both static and shared libraries.
A static library can use both static and shared libraries.
A shared library can only use static libraries.
I have still doubts about the third affirmation...
Can you enlighten me on this?
To use a static library's basically like linking a .o or .obj file: all the implementation's linked into the using application or library at that specific point in time. Changes made to the static library after that time won't be picked up automatically by the code that linked it... the latter would need to be relinked for the changes to be incorporated.
Shared libraries defer the linking until runtime, which means every time the code using a shared library invokes some functionality within it, the version of the shared library which is found at runtime is utilised. As long as the changes don't affect the public API, you can replace a shared library and applications that find it at runtime will pick up the updates/changes without themselves having to be modified/relinked.
So, yes an executable can use both, a static library can use both, and your third "affirmation" is wrong: a shared library can also use both. It just means the shared library itself may use a snapshot of functionality from a static library, or it may find other functionality from another shared library at runtime.
I have certain doubts:
Use case:
A static library containing a global variable, static variable, a function
and a class defined
A shared library uses these and hence they are part of the same.
A executable program also uses the same and they are part of the same.
The executable loads the shared library on run time
What all differs between windows and Linux?
Can the shared library use something from executable's static library objects?
Can the executable use something from shared library's static library objects?
What is the role of loader? For ex: does the static library objects in static library are shared between shared library and executable on Linux?
Is there any difference if the shared libraryis loaded at runtime or load time?
In the library that you define your global static you can define it as follows:
static int g_i=9;
when accessing g_i from other modules then you should use extern to tell the compiler that g_i is defined in another module:
extern int g_i;
This is all Standard C and there should be no differences between the different C compilers regardless of operating systems.
A library can't reference anything in the executable since that would cause a circular reference, rather you should take the shared functionality in the executable and add it to a third library that is referenced by both the existing library and the executable.
There are different use cases where you rather want dynamic loading over static linking. Static libraries makes your executables larger, while dynamic libraries can cause "DLL Hell". Mostly people use shared libraries when they want to share the code between different programs and use static libraries when they only are going to use the library in only one program.
I have one c++ Project that contains the principal binary that is : prog.CGI.
This is linked to one shared library called : Core.so,
I'd like to know if I can also link another shared library called : ext.so to Core.so because ext.so use structures defined into Core.so.
Yes, shared libraries can be linked to other shared libraries, and commonly are. You can use ldd to explore dependencies between them.
I'd like to build both static and shared libraries in a project.
I know that shared libraries need to be be created from objects compiled with -fpic to get Position Independent Code while the static library doesn't need this. This is all fine and I can create either a shared or static library.
I wouldn't want to compile my source twice to get the different object files, so how is this usually done? I read how to get a shared library based on a static one. However, the example shows the static library being built with -fpic. Is this the way to go? Are there things to be aware of with this?
Is there a common approach to compiling both static and shared libraries? E.g. first static and based on the lib a shared version is created?
I'm interested to know if there are different approaches for this and what to consider when selecting.
I'm using gcc4.4 on Linux.
Thanks in advance!
The common approach that I've seen is, in fact, compiling your source twice, once with PIC and once without. If you don't do that, you either wind up with PIC overhead in the static library, or a shared object that can't be relocated by the OS (effectively meaning it's NOT shared across multiple clients of the library).