To give you a practical example. By default on Windows Qt (any version) would statically link SQLite as part of it's own QtSql's SQLite driver (which is a .dll

To give you a practical example. By default on Windows Qt (any version) would statically link SQLite as part of it's own QtSql's SQLite driver (which is a .dll - so that .dll would contain in itself sqlite). If you happen to link SQLite additionally because of some other lib, then you would end up with two different libs in the same code (but under different "namespaces" in a way). With static linking one of the libs would've took precedence, unless you've decided to embed "sqlite3.c" directly - then I think your copy would've took over Qt's one (static Qt5sql.lib) To avoid this problem, I manually built Qt5 and made sure most of the libraries are split out of Qt5 - angle, pcre, ucdn, sqlite, mysql, libpq (postgres), etc. - they are all dlls that both Qt and rest of our apps link to. This also allows us to use and share SQLite memory db (for the memory db to be shared it has to come from the same code), where we are letting coders to use QtSQL's approach to access the db, and then other access it other ways. It's non-standard on Windows - since you are basically eating whatever you have been served (in the Windows World), and you don't think much about picking (static/dynamic library, then linking to static/dynamic CRT, compiler version, etc.). Things are much better, say in debian (my experience) - installing qt5-sql would use the sqlite package from the system, and the rest of my tools would do that too.