Static Linking vs Dynamic Linking for LGPL-Compliant Qt Distribution

Answer

For a clean OS target, the most sustainable balance is dynamic linking. It satisfies LGPL’s “allow modification” requirement automatically, keeps binaries small and update‑friendly, and lets you ship a reproducible runtime environment with tools like windeployqt, macdeployqt, or linuxdeployqt.

Why Dynamic Linking Is Preferable

• LGPL permits dynamic linking without extra work – users can replace the shared libraries.
• Deployment tools bundle the exact Qt plugins needed, so the runtime environment is fully controlled.
• Updating a Qt library (e.g., to patch a bug or add a feature) only requires replacing the shared library files; the application binary stays unchanged.
• Binary size is typically 30‑50 % smaller than a statically linked build, easing disk and memory constraints.

When Static Linking Might Be Worth It

• Performance critical paths where the overhead of a dynamic linker is unacceptable.
• Environments where the Qt runtime cannot be shipped (e.g., embedded devices with strict size limits).
• Regulatory or policy constraints that forbid dynamic libraries on the target platform.
• You can afford the extra distribution effort: provide the object files for every module you link and a clear re‑linking path.

Practical Steps for Dynamic Deployment

1. Build normally with CONFIG += qt and no static flag.
2. Run the deployment tool for your platform:

   windeployqt MyApp.exe
   # or
   macdeployqt MyApp.app
   # or
   linuxdeployqt MyApp.AppImage -appimage

3. Include the LGPL‑3 license text in your installer or documentation.
4. Provide a notice that the application uses Qt and that users can replace the Qt libraries.
5. Optionally ship a small helper script that verifies the presence of required Qt plugins and offers to download missing ones.

Practical Steps for Static Deployment (If Chosen)

1. Enable static linking in your project file: CONFIG += static and link against the static Qt libraries.
2. Collect object files for every Qt module you link. These are typically found in qtbase/src/corelib, etc.
3. Bundle the object files alongside the executable, and provide a clear README on how to relink the application with modified Qt code.
4. Include the LGPL‑3 license text and a notice that the binary is statically linked.
5. Test that a user can rebuild the application using the provided object files and a modified Qt source tree.

Key Decision Criterion

Measure the cost of shipping and maintaining object files against the risk of a runtime failure on a clean OS. In most production scenarios, dynamic linking offers the least friction while fully complying with LGPL‑3.

Missing Diagnostic Detail

Could you list the Qt modules you plan to link (e.g., QtWidgets, QtWebEngine, custom plugins)? If any module is not covered by LGPL (or has additional patent clauses), dynamic linking may be the only compliant path.