*Disclaimer: I am a newbie who is trying to learn about how to use third party libraries. *
I’m looking at using libcurl for a project and I want to statically link it to my project so that it is included in my final executable.
Some documentation online says:
By default, configure will setup the build files so that the following make file command will create both shared and static versions of libcurl. You can change that with the —disable-static and —disabled-shared options to configure.
If you instead want to build with static versions of third party libraries instead of shared libraries, you need to prepare yourself for an uphill battle....
Are they talking about the libraries that libcurl uses? I guess what I’m asking is: even if I build libcurl and link statically, will libcurl still be linking dynamically to 3rd party libraries?
Is that what this is saying?
The thing is, a static library is really nothing more than an archive of object files. Linking with a static library is the same as linking with the separate object files themselves. That means that any 3rd party dependency that the library have also becomes a dependency for your application. And you must link with those 3rd party libraries and dependencies when you link your application.
Now for libcurl itself, depending on how you configure and build libcurl, it may depend on some 3rd party libraries that can't be linked statically to your application.
So to answer your question: It depends.
It mostly depends on how you configure it for building, and what 3rd party libraries you tell it to use, and if those 3rd party libraries are available as static libraries (and then on to their dependencies and so on).
Related
I want to build a library which is easy to use and link to. Therefore, I do not want the user of my library to bother with building and linking against the libraries my library uses. What is the best approach of managing and building/linking the dependencies for your own library in order to assure the most simple usage of it?
E.g.: My library uses CURL and OpenSSL. Building and linking on Windows with those dependencies is a pain. I want to avoid this pain to the users of my library.
I use CMake for building.
Related to: Combine libraries and Linking static libraries to other static libraries
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 have built a shared library that depends on a bunch of other libraries. But when loading that shared library, it needs the dependent libraries to be present in order to run properly. I want this shared library to be portable and hence want it to contain all the dependencies in itself. Is there a way in cmake to do this or what is the best solution here?
Actually this is not related with CMake, but with concepts of linking. You should link with static version of all your dependent libraries.
I'm building an application using Qt 5.8 and setting up for static builds (since this seems to be the best way to get OpenSSL working when deploying the application to other computers). However, we also have a dependency on WebEngine which cannot be built statically.
Is it possible to build the application using a statically built Qt5.8 but still dynamically link the WebEngine libraries when compiling?
I can get the application working with a fully dynamic build - so will it simply dynamically link any libraries that weren't built into the static compiler? Obviously, I will still need to provide the dynamic library with the executable when deploying.
Yes you can. Almost all build systems used in Qt (qmake, cmake, qbs) provide easy options for linking both static and dynamic libraries.
What build system are you using?
Yes, you can do it. I had to build Net-SNMP which gave me a ./configure file in which I mentioned the shared and static library, wherein the system libraries were dynamically linked and OpenSSL was statically linked.
You can go through ./configure file post downloading Net-SNMP and go through the file which does the same task and tweak the values according to your usage and environment.
Additionally, go through link 1 and link 2 which will give you a brief idea about how to create a shared and dynamic library.
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.