What is the best practice for deploying your application as a static or dynamic build?

I plan to release and deploy an application written in C ++ and wxWidgets. The wxWidgets library is available both as a DLL and as a static library. Therefore, I have the opportunity to deploy the application as a dynamically created application or as a static assembly.

I currently prefer the static build option because:

  • the executable is not too large (<20 megabytes).
  • There are no dependencies to consider.
  • no installation required.

Question

Did I miss something very important?

+5
source share
3 answers

My suggestion was to switch to static binding . My two cents for the most part:

  • You do not depend on the WX toolkit installed on the client site, and you do not need to specify it bundled with your installer, and not as a standalone installer as a prerequisite .
  • You do not expect or ask the client to complete the WX installation (or even XCOPY deployment). Customer is not worried!
  • 20 MB is quite small in the TB of the world and good MB Internet speeds.
  • You do not get unexpected behavior errors from the client if they use a higher / lower version of the library.
  • You can be sure that the application will work just as you tested in your environment (mostly)
  • You can continue to use the X-version of WX, even if an error occurs with the error / flashy X + 1. You do not want the client to have a “new and improved” version of the library that crashes your application!
+3
source

You should use dynamic linking when there is good reason to use it and static links otherwise. Some good reasons to use dynamic binding:

  • You distribute binaries for a system that already has or may have wxWidgets libraries, such as a number of Linux distributions, OS X (with Homebrew), etc. In this case, it is strongly recommended that you reuse existing system libraries and not use your own.
  • You have several modules using wxWidgets: space savings when using dynamic linking can be quite significant.
  • You use wxWidgets from a DLL in MSW: in this case, wxWidgets itself must also be linked as a DLL, otherwise you run the risk of problems if more than one wxWidgets instance is loaded into the process address space.
  • You plan to update the installation of your application over the network: in this case, it might be nice to be able to update only one DLL instead of the whole monolithic application.

If none of these reasons apply, for example. you just want to distribute one program under MSW, static linking is simpler and preferable.

Relative note: if you end up distributing wxWidgets DLLs, consider using a unique suffix for them instead of the default “custom” suffix, this will reduce the chance of confusion between your DLLs and some other version of wx.

+4
source

Although in your case the executable is not very large, it can become extremely large if you link everything statically. It also uses more memory since a large executable must be loaded into memory.

If you want to use a dynamic library, the operating system can “share” read-only memory between processes, which reduces memory requirements.

Updating your program can also be easier with a dynamic library, because instead of updating the entire executable, you can simply replace the dynamic library (provided that its interface is the same) and voila! The same thing happens if the user wants to update his dynamic library (for example, through the package manager).

+1
source

All Articles