Static Library Link

[ldicker83]

Project settings for OP2Utility uses static linking for the run-time library -- out of curiosity, why was this choice made? It necessitates that other applications developed using OP2Utility also link to the run-time library statically instead of using the DLL versions. While not necessarily the biggest issue in the world, it does create a larger binary file and can cause confusion to users who aren't aware of this option.

[DanRStevens]

No runtimes to distribute is one of the big reasons. If you use dynamic linking, you often end up telling people to go to the Microsoft website to download/install the MSVC runtime separately. Depends a bit on which version of Windows they're using, and which version it was compiled with, which often catches developers by surprise since they're generally using the same version they are compiling on.

I haven't looked much into the issue with downstream project settings.

[Brett208]

I think @ldicker83 is correct that more often Windows projects use dynamic linking. In my experience, sometimes using static linking has caused complications in linking to other projects since it is less common.

A lot of the early static linking I think was driven by Wine compatibility for missions which was thought to be eased by static linking. I know NetHelper had problems since it targeted a very recent version of the runtime library and would just silently fail if it wasn't present until we switched it to static compilation.

By linking to an old enough runtime library, one may be able to ensure anyone not using a very old machine had the library already installed. I think just statically linking nicely eliminates the problem, especially since executable size matters so little for this type of application. I just wish it were a bit easier to link against.

Many large projects offer both a static and dynamic compilation option. Maybe we want to support both? Ideally OP2Utility should not prevent a downstream application from being either statically or dynamically linked against.

[DanRStevens]

With NuGet packages, I've noticed they are often distributed with a tag for both statically linked runtime and dynamically linked runtime. For libraries, they also vary in another dimension, of being either a static library or a dynamic link library themselves. Hence libraries are often packaged as 4 different variants. Perhaps we should do similar.

[ldicker83]

Been a few years, wanted to poke this issue again. Since we've been using vcpkg almost exclusively it might be interesting to look into offering that.

In the mean-time I've updated op2-landlord to use OP2Utility as a submodule. In order to get it to build I had to 1) update to vs2022 and 2) change linking to multi-threaded DLL. In a case like this it's an almost trivial process so that might be something to include in the docs.

[DanRStevens]

Just realized I should leave an update here. The project was updated to switch from NuGet to Vcpkg for dependencies. As part of that change the RuntimeLibrary setting was changed to use the DLL versions of the CRT. I'm realizing now that may require updates to downstream projects if they had been set to use static linking.

Related:

• PR Switch to vcpkg for dependencies #444
• Issue Modernize build workflow #414

---

There is some ongoing effort to update downstream projects such as:

• OP2Archive
• MissionScanner

I suppose maybe I should add op2-landlord to that list.