CPP runtime doesn't work "out-of-the-box" under Windows

[Rüdiger Franke]

Consider the following test:

1. Install OpenModelica1.9.3Nightly on a fresh Windows 7
2. Start OMEdit and add +simCodeTarget=cpp to OMEdit->Tools->Options->Simulation:OMC Flags
3. Simulate the model Modelica.Blocks.Examples.PID_Controller

The log window reports:

Process crashed
Simulation process failed. Exited with code -1073741515.

Then open a DOS prompt in OMEdit's working folder. Unfortunately OpenModelica does not tell which path it needs. Let's assume something and invoke the simulation executable:

> PATH=%PATH%;C:\OpenModelica1.9.3Nightly\bin;C:\OpenModelica1.9.3Nightly\lib\omc\cpp
> Modelica.Blocks.Examples.PID_Controller.exe

This results in a dialog box saying that MSVCR100D.dll is missing on my Windows 7 machine.

Does this mean that some dll that is loaded by the model was wrongly compiled with cl in debug mode?

[Marcus Walther]

I can reproduce the first issue that you have reported (the error code -1073741515), but not the second one with the MSVCR100D.dll. I can execute the code without problems if I export the described paths. I have inspected the generated Modelica.Blocks.Examples.PID_Controller.exe and OMCppModelica.Blocks.Examples.PID_Controller.dll and non of them is linked against MSVCR100D.dll.

However, the "D" in the library name stands for debug and these libraries are not part of the visual c++ redistributable packages, they are only part of visual studio itself.

I think the problem occurs, because the c++ runtime is build in debug mode. So all boost libraries are linked in debug mode as well and maybe the boost extension library searches for the debug libraries of visual studio at run-time. We should change the build type of the c++ simulation runtime to release. This can be done by switching the BUILDTYPE in SimulationRuntime/cpp/Makefile or SimulationRuntime/cpp/Makefile.omdev.mingw.

@Adrian: I can easily implement a switch for linux/mac with the help of configure. For Windows we need a make-variable that we can read in SimulationRuntime/cpp/Makefile.omdev.mingw to decide if release or debug code should be used. Do we have such a variable?

[Adrian Pop]

@Rüdiger: I don't think we set the path to %OPENMODELICAHOME%\lib\omc\cpp in OMEdit when running the executable and maybe that's why we get (the error code -1073741515) as there are needed dlls there. I'll have a look. The trouble is that depending of +target=gcc|msvc the paths should be different, so if a user adds +target=msvc flag, then that executable will not work as it would also need %OPENMODELICAHOME%\lib\omc\cpp\msvc in the path.

@Marcus: We could define the BUILDTYPE=Debug in the SimulationRuntime/cpp/Makefile.omdev.mingw only if is not defined from upper level. So, the default behavior would be to build in debug mode.

Then when building the OpenModelica installer, I can build the MSVC/GCC CPP runtime using:

BUILDTYPE=Release make -f Makefile.omdev.mingw runtimeCPPmsvcinstall
BUILDTYPE=Release make -f Makefile.omdev.mingw runtimeCPPinstall

For this to work we need to pass BUILDTYPE down from the OpenModelica glue project makefile to OMCompiler makefile and to SimulationRuntime/cpp/ makefile similar to what we do with OMBUILDDIR. I will give this a try.

[Marcus Walther]

Adrian, it would be nice if you can add the BUILDTYPE-Variable to the windows-makefile. I have added the configure flag for linux/mac (currently the hudson-pull-request is running). So maybe you can add "--with-cppruntime-args=BUILD_TYPE=Release" to the configure-command of the super-project, if you build the linux-packages.

[Rüdiger Franke]

@Adrian: under Linux the -Wl,-rpath option is used to add the approproate cpp path the the generated executable.

[Adrian Pop]

@Rüdiger: yes, but that doesn't work in Windows. I now added the needed path to OMEdit 3845a6/OpenModelica.

I also fixed the Windows makefiles to build the release for the CPP runtime.

[Adrian Pop]

@Marcus: it seems the build of runtimeCPPmsvcinstall does not work when BUILDTYPE=Release, see:
​https://test.openmodelica.org/hudson/job/OM_Win_NIGHTLY_BUILD/1369/console

[Adrian Pop]

@Rüdiger can you check with the latest nightly build if this problem is solved?
​https://build.openmodelica.org/omc/builds/windows/nightly-builds/
I will try it myself too and try to see what dll dependencies the generated executable has.

[Adrian Pop]

The fix seems to be working, I can simulate the model and plot the results. The only error I'm getting is this:

[1] 06:04:08 Scripting Error
Error opening the file C:/Users/adrpo/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Blocks.Examples.PID_Controller_init.xml. No such file or directory

@Adeel: I wonder why OMEdit wants to read this.

[Adrian Pop]

Also, as a note the executable generated by CPP runtime does not support some C runtime options:

stdout | error | <p>Warning: unrecognized command line options -port=8792 -logFormat=xml -override=variableFilter=.* -dasslJacobian=coloredNumerical -lv=LOG_STATS -w

We should maybe open a new ticket about it?

[Marcus Walther]

Replying to adrpo:

@Rüdiger: yes, but that doesn't work in Windows. I now added the needed path to OMEdit 3845a6/OpenModelica.

I also fixed the Windows makefiles to build the release for the CPP runtime.

For this purpose I've added a path-export to the generated .bat-file, but OMEdit invokes the .exe directly, so that's why the path is not correct.

Replying to adrpo:

@Marcus: it seems the build of runtimeCPPmsvcinstall does not work when BUILDTYPE=Release, see:
​https://test.openmodelica.org/hudson/job/OM_Win_NIGHTLY_BUILD/1369/console

Thank you for the info, I will have a look at it.

Replying to adrpo:

Also, as a note the executable generated by CPP runtime does not support some C runtime options:

stdout | error | <p>Warning: unrecognized command line options -port=8792 -logFormat=xml -override=variableFilter=.* -dasslJacobian=coloredNumerical -lv=LOG_STATS -w

We should maybe open a new ticket about it?

I will open a new ticket about this issue. Is there a list of flags that are used by OMEdit?

[Rüdiger Franke]

We implemented mappings for options that address existing features of the C++ runtime. These are in particular the override options (see OMCFactory::preprocessArguments):

          std::map<std::string, std::string> supported = map_list_of
              ("startTime", "-S")("stopTime", "-E")("stepSize", "-H")
              ("numberOfIntervals", "-G")("solver", "-I")("tolerance", "-T")
              ("outputFormat", "-O");

Moreover we made sure that there are no naming conflicts (C options start with one dash and a small letter, C++ short options start with a capital letter, C++ long options start with two dashes). Unrecognized options are collected and issued as the warning that you posted.

I agree that we should further harmonize the runtimes. The -port is certainly an important addition. All options can't be supported -- there is no dasslJacobian in the C++ runtime, for instance.

Also #3321is related.

[Rüdiger Franke]

@Marcus: all options that are written to the .bat file should also be compiled into the simulation executable, in order to make it possible to call it directly. See CodegenCpp.tpl, line 2266ff:

      // default program options
      std::map<std::string, std::string> opts;
      opts["-S"] = "<%start%>";
      opts["-E"] = "<%end%>";
      opts["-H"] = "<%stepsize%>";
      opts["-G"] = "<%intervals%>";
      opts["-T"] = "<%tol%>";
      opts["-I"] = "<%solver%>";
      opts["-R"] = "<%simulationLibDir(simulationCodeTarget(),simCode , &extraFuncs , &extraFuncsDecl,  extraFuncsNamespace)%>";
      opts["-M"] = "<%moLib%>";
      opts["-r"] = "<%simulationResults(getRunningTestsuite(),simCode , &extraFuncs , &extraFuncsDecl,  extraFuncsNamespace)%>";
      <%if (stringEq(settings.outputFormat, "empty")) then 'opts["-O"] = "none";' else ""%>

Is there something missing for the Windows build?

[Marcus Walther]

Niklas is working on a fix for the visual studio issue.

[Rüdiger Franke]

We still have the dependency on MSVCR100D.dll in the beta release :-(

But at least the error message has improved from "Process Crashed" to "Failed loading CVode solver library", meaning that it should work once Visual Studio is installed.

[Rüdiger Franke]

@mwalther: Compiler optimization and debug flags have disappeared from "ModelicaConfig_gcc.inc" under Linux. Formerly the SYSTEM_FLAGS contained "-O0 -g". Both have disappeared. Is this related to your recent changes?

[Rüdiger Franke]

Along with "-O0 -g" also "-DNDEBUG" disappeared from the system flags. This causes the new issue #3428 (10 failed MSL 3.2.1 tests). It has been introduced as well as #3429 (bad logging) and #3427 (suppressed warning) after the tagged version 1.9.3beta.

Btw. the Windows release of OpenModelica contains MinGW with debugging. Compilation with -g just works fine (and is also needed for the algorithmic debugger).

After having added the path to OMEdit (comment:7), the Sundials dlls seem to be the remaining problem, see

c:/OpenModelica1.9.3-dev.beta/bin/sundials_*.dll

They depend on MSVCR100D.DLL, such as sundials_cvodes.dll and sundials_kinsol.dll loaded by the simulation executable through libOMCppCVode.dll at runtime.

[Marcus Walther]

@Adrian: Rüdiger gave the correct hint. The libraries in OMDev\lib\3rdParty\Sundials\lib\release\vc100 are linked against the visual studio debug library. Can you please rebuild them correctly? I do not really understand why this dll is loaded, because we do not use the MSVC. Maybe because he cannot find the MinGW libSundials*.dll files. In the nightly build they are neither part of the bin-folder nor of the lib-folder. I think they should be part of the bin-folder, so maybe we forgot to copy them?

[Adrian Pop]

@Marcus: I will include the compilation of sundials in the building so we compile it during the OpenModelica build. This way we can play with flags as we want and not depend on binaries.

[Adrian Pop]

I opened #3439 to deal with 3rdParty includes.

[Adrian Pop]

Should be fixed with commit 865e87c23a360b8a90121507cec25d3f1e144f0b/OMCompiler and will be part of the next nightly build.