cosim-cli should be compiled with `shared=False` by default

[Lars T. Kyllingstad]

Over the years, we've run into multiple cases of run-time dependency conflicts between Cosim (or its precursor Coral) and FMUs. The conflicts come in two different varieties:

1. Both Cosim and the FMU depend on the same shared library, but in different, incompatible variants/versions. Cosim's dependency will be loaded first and the FMU will be dynamically linked to it, causing crashes and other problems. (Some libraries, like zlib, are popular enough that this risk is actually pretty high.)
2. The FMU calls a function from one of its shared library dependencies, but one of cosim's dependencies have a function with the same name. Since cosim's dependency was loaded first, it will be selected by the dynamic linker, and we're in UB territory. (We recently came across this issue with libzip's zip_close(), when an FMU tried to call a function also called zip_close() from a completely unrelated library.)

These problems can be worked around by spawning off a new process for the FMU using proxyfmu, but that is not always a desirable solution.

I think the most sensible thing to do would be to make static compilation the default for cosim. That way, all symbols are resolved at compile time and won't interfere with any symbols dynamically loaded by the FMU. Since we don't have any control over what FMUs will be run with cosim, this seems like a low-effort way to reduce the risk of conflicts.

Note that if we want to distribute statically linked binaries, then we also need to make sure that the licences of all dependencies are compatible with ours.

[Lars T. Kyllingstad]

By the way, there is a related kind of conflict that we can't do much about, which is dependency conflicts between FMUs. This could happen if two FMUs in the same co-simulation depend on incompatible variants/versions of some shared library. (The proxyfmu workaround works here too, fortunately.)

At the very least, we should document these issues and provide advice and possible solutions in the README.

[Kristoffer Eide]

Sounds good!

[Lars T. Kyllingstad]

Upgrading this from a question to an enhancement, as it has now been discussed and agreed upon by the OSP committee.