Compiling as shared library

[jowr]

I have tested the shared library compilation with Dymola 2022x on Windows. That seems to work fine. However, could any of you OM guys take over from here? I would be happy to help with CMake etc, but I am not familiar with OpenModelica at all...

[jowr]

I would recommend that @casella, @albertoleva and @fedetft have a look at the branch v4-dev and provide some feedback here.

[fedetft]

Tried building the v4-dev branch on Linux and testing with openmodelica, used these commands:

cmake -B build -S Projects -DCMAKE_BUILD_TYPE=Release
cmake -B build -S Projects -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release --target install

no issues found in the building step.

Trying to run a model such as ExternalMedia.Test.CoolProp.CO2.TestStatesSatSubcritical however I still encountered two issues:

1. openmodelica complains it can't find the library. It's the old issue that on linux the library should be in the Resources/library/linux64 and not in Resources/library/linux64/gcc94, which is where the install target puts the library. Incidentally, I noticed that the file libExternalMediaLib.so.4.0.0 (but NOT the libExternalMediaLib.so symbolic link) is also copied in the Resources/library directory, and I don't know why, but openmodelica does not look for the file there. By moving the content of the gcc94 directory one level above, openmodelica finds the library, but the following issue occurs
2. OMEdit crashes when checking the model ExternalMedia.Test.CoolProp.CO2.TestStatesSatSubcritical, it appears that it tries to load the shared library to call the functions to initialize the package constants, but something goes wrong and it crashes

NOTE: to get the model to run I had to edit a few Modelica lines here and there, like "SI.IsothermalCompressibility > Modelica.SIunits.IsothermalCompressibility" probably because I'm using a different MSL than you,but I don't think this is the cause of the crash above.

[fedetftpolimi]

The crash problem was due to
OpenModelica/OpenModelica#8738
which has been fixed but at the time of writing an OpenModelica build with the fix has not been released yet.

[casella]

We need to handle the error functions in ExternalMedia. This is potentially a problem in case of dynamic linking, because the ModelicaError, ModelicaWarning (and in fact all ModelicaUtilities) functions may not be available inside the library when compiled as a dll/so. This issue was actually discussed some years ago in ModelicaSpecification #2191, but then the discussion got nowhere, probably for lack of strong end-user motivation / available time.

@fedetftpolimi, who is a compiler and OS guru, figured out a very simple solution to that problem: you just need to export all the ModelicaUtilities symbols in the compiled simulation executable, and also in the Modelica compiler GUI, since ExternalMedia may be called at compile time as well, because of evaluation of package constants. This guarantees that the functions in the ExternalMedia dll can access them. This can be done both on Linux and Windows, and we know how to do that. However, this requires all tool vendors to agree to the principle and implement it in their tools, which is a bit of a lengthy process. In fact, Dymola does it on Linux, but apparently not on Windows, for some reason.

We will start that discussion in #2191, but for the time being we figured a relatively simple hack that should work in all cases and does not require to change the structure of all ExternalMedia functions to have them return an error code string in case of trouble.

The idea is that, at runtime, the first ExternalMedia function that is called is always a setState_XX function. There are only six of them. We just need to add a C wrapper function defined in the include annotation of the corresponding Modelica external functions, that passes to the actual library functions a pointer to ModelicaError. These C wrappers are statically compiled with the simulation code every time a model is generated, so they have access to that function and can pass the pointer further down the line. The first called setState_XX library function will then copy that pointer to a global static variable of the library, from which the errorMessage function will be able to retrieve it. In this way, all other external functions can be left unchanged, as they can safely call errorMessage, which will know what to do.

We'll implement the new errorMessage handling next week, with a bit of luck we should finally get ExternalMedia to run on OMC as well.

Since I'd like to have a MSL 3.2.3-compatible version that works in OMC to run legacy models using ExternalMedia, we have cherry-picked your changes regarding the shared library compilation, and then we'll release 3.3.2 and 4.0.0 based on that.

[casella]

We are almost done with that, see the dynamiclib branch. Only a clean-up of the build scripts needs to be performed

[fedetftpolimi]

Fix merged to master.