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.
Related
I just wanted to understand how shared libraries with statically linked libraries are expected to perform. I am writing a shared library (lshared.so) that is statically linked to another library (lstatic). Now, I have another executable helloworld which loads a dynamic version of library lstatic (lstatic.so) and lshared.so as well. Will the static version of library (lstatic) loaded by lshared.so and the dynamic version (lstatic.so) conflict? Will they share any global state? Tried to show it better below.
helloworld
--> lshared.so (statically linked to lstatic at compile time)
--> lstatic.so (hello world loads this at runtime)
To throw some context, I've to use a shared library for logging. It is possible that lshared.so is statically linked to a different version that the one available to helloworld at runtime.
Will the static version of library (lstatic) loaded by lshared.so and the dynamic version (lstatic.so) conflict.
Possibly.
Will they share any global state.
Possibly.
The answers depend on how exactly lshared.so is built (which symbols it exports), and how the main helloworld binary is linked.
The answers also tend to be somewhat complicated, and may depend on inlining and other optimizations, and possibly on compiler versions.
It is best to avoid doing that by using shared version of lstatic.so, where all the answers become simple.
so I know that you can't depend a static library to another one but i was wondering if there is something that lets me combine them together. I am trying to setup a game engine project file in vstudio 2019 and i want to compile it as a static library. I need in some way to combine it with SDL 2 library because I want create some systems using SDL. Is there a way I can do that?
Thanks for the help.
When creating a library, you can specify "Additional dependencies" in the "Librarian" properties of the project. The dependency may be another library. Also set "Link Library Dependencies" to "Yes" so that the whole library is included.
Sure you can have one static library depend on another. A static library is, roughly, a collection of independent compiled objects, with a "settling" of their provided and required symbol table. Those symbols that aren't found within the static library itself continue to be dependencies, which may well be provided by another static library.
Depending on your platform, there are tools for working with compiled libraries. On Unix-like operating systems, you would use the ar utility to combine static libraries ("archives") in various ways:
How to merge two "ar" static libraries into one?
On windows, there's the LIB.EXE tool. See:
How to merge two windows vc static library into one
I'm currently developing a shared library on Windows (dll) with c++.
The library depends on another external library.
What is the best way to link them together?
Link the external library as a static library into my shared lib?
Link it as a shared library and provide the dll to the application who is using my shared lib?
For the second case what happens if i create an application which uses my own created shared library and also the external library as a shared library?
If for example my shared library is build with the external library version 1.1 and the application uses the newer Version for example 1.3 ? Now the dlls should be different but how could i provide them to the main application?
Are there some best practices or recommendations on how to handle such a situation?
This really depends on what you want to do and how you are deploying your library.
shared/dynamic libraries (dll's on windows) have several advantages over static libraries
They can be distributed externally from the application, allowing your application binary to be smaller
They can be updated externally to the application
They are slightly more efficient as code is only executed if its needed rather than being bundled with the executable
Of course they have several weaknesses too
They can be distributed externally from your application and updated externally - allowing dll injection attacks
Trying to release dynamic libraries with the executable is one of the most painful and horrible things to do (especially on windows where there is no RPATH)
You may have to use a dll, dependent on your external libraries licensing, Qt for example requires shared library linking in many cases (not all).
Standard convention is usually to offer shared and static versions of your library with the shared version being completely linked to other shared libraries and the static version being an ar static library (includes all dependencies). The shared library variant then offers instructions on linking (i.e a .pc (pkgconfig) file) which specifies the versions of the other libraries to link to (i.e v1.1 of x.dll) in order to successfully compile/link.
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.