Best practice: dynamic or static libraries

posktomten

Hey!
I've looked around the forum (which I should have done before writing the question.) and read a bit elsewhere.
Now I feel convinced that consistently using linked libraries means less trouble and more benefits. Not least if you also write programs for Windows. With Windows operating systems, it is particularly difficult and can easily go wrong. This is just my opinion.

jeremy_k

@posktomten said in Best practice: dynamic or static libraries:

Now I feel convinced that consistently using linked libraries means less trouble and more benefits.

I think there's a word missing. Is this referring to dynamic or static linking?

posktomten

@jeremy_k said in Best practice: dynamic or static libraries:

dynamic

@jeremy_k
That must be called ambiguous! :-)
I mean dynamic linking.

jeremy_k

Interesting conclusion.

While some libraries make building static versions more complicated, I think of their final deployment in an application as easier. Because the library code is incorporated into the executable, there's no reasonable potential for the library to be missing at runtime, or for the wrong version to be used.

Dynamic libraries should only help if used by multiple applications (not multiple invocations of 1 application), or if the libraries will be upgraded independently of the application.

And then there's plugin loading.

posktomten

@jeremy_k
That was my original thought. I've had trouble getting it to work with Windows. Linux works perfectly (with static linking, *.a.files). And my libraries are probably not used by anyone else. (Library for: Update AppImage, create shortcuts in the program menu and on the desktop, Check for updates, view "About", download NSIS offline installer) practical to be able to reuse.
Now is the time to think about something else, to let the thoughts clear!
Thanks for your point of view!

Kent-Dorfman

This is a good one for a flame war. LOL

The accepted practice these days would be DLL so objects. I have issue with this, as I have issue with many current practices. In my world there is sometimes reason to create a statically linked executable, and gets harder and harder to do so as time goes by. Take pthreads, the posix threads implementation in linux. It has been BBD (broken by design) for 15+ years. The devs know the problem, but they ignore it because DDL/so is the workaround. If yer interested, the problem with pthreads is that there are symbols in it with weak bindings/references that disallow it to work when the pthreads.a archive is linked to the executable. You HAVE TO use the dynamic .so version.

Please, please, please create both archive .a and DLL .so versions of your libraries...and actually test them.

SimonSchroeder

I might be chiming a little late.

We used to have DLLs on Windows (mostly for Qt and the VS runtime). This was (in some software still is) a PITA. It is much easier to just have a single application file that you can copy around. (This is important for commercial software which is used by our clients as well who are not necessarily tech savvy.) Now, we link everything statically on Windows because it is a lot less painful. The system will not accidentally find the wrong DLLs on the developers' systems. We haven't had a problem with "But it runs on my system" for a long time.

That being said: Our primary goal is to have a single file for the application. The only way for Windows I know is static linking. However, on macOS we have the App Dir which works well with all the dynamic libraries included. On Linux, we use AppImages instead which also include all the necessary dynamic libraries. Basically, on all platforms we have a single "file" to copy around which is self-contained. (The reasoning for Linux to include all DLLs is because it will work on most distributions.)

JoeCFD

@posktomten Be aware that it is not free for commercial use if you statically link Qt libs or many open source libs to your apps. Also it is easier to maintain your big app with dynamically linked libs. Often it is much quicker to simply build a dll or a so lib only when some changes are made.

posktomten

Thanks for all the comments!
The question I'm thinking about only applies to my own libraries. If they should be linked statically or dynamically to my own program. It doesn't really matter much.
Advantage of statically linked library files:
"All in one file", The risk that something would stop working with the linking is very small.
Dynamically linked:
Less to update. For Qt Installer Framework with online installer it can be smooth.

On the other hand, I distribute my programs as AppImage (linux) or Online (Qt Installer Framework) and/or offline installer (NSIS) in the case of Windows. So it doesn't really matter.
All open source.

In between, I've compiled Qt statically so that everything can really be deployed in one file. In some cases there have been problems.

paulf

I recommend reading this book

https://books.google.fr/books/about/Linkers_and_Loaders.html?id=Id9cYsIdjIwC&redir_esc=y

It's pretty much the only one on the subject.

As already said

static libraries

smaller system memory footprint for a single project
no sharing so larger memory footprint if used by more than one application
can't update the library easily unless you fancy binary patches
faster access to global variables
slightly faster global function calls
better portability (no need for DLLEXPORT/DLLIMPORT on Windows)
no DLL / LD_LIBRARY_PATH hell (there are ways to avoid LD_LIBRARY_PATH hell but most devs seem to be ignorant and never use them)
if it links it should run whilst usually shared libs are linked without resolving all symbols meaning it's only when you run that the link loader resolves all symbols (also possible with the link editor but hardly ever used)

dynamic libs

can have very fast but unsafe linking (an option with XCode at least)
gives possibilities of replacement e.g. using LD_PRELOAD
if your application is fully static (no dynamic linking at all) then you won't be able to use tools like Valgrind that need LD_PRELOAD