Cross compilation of binary FMUs

[Rüdiger Franke]

Use cases for cross compilation are:

1. the development platform differs from the target platform (e.g. embedded or win64/win32)
2. one and the same FMU shall run on multiple target platforms (like a desktop PC for testing and embedded device for production)

These use cases are fulfilled with the compilation of binary FMUs for different platforms. The existing cross compiler features shall be exploitet, in particular the different gcc packages under Linux.

This implements the buildModelFMU command for the Cpp runtime.

[Martin Sjölund]

Milestone renamed

[Rüdiger Franke]

fea7a0a/OMCompiler (and the subsequent fix) separate dynamic from static build of the runtime. This allows to only generate one version if the other is not needed. Only the static runtime is typically used for cross compilation. This also speeds up code/compile/test cycles when e.g. the dynamic version is sufficient for developing new features.

As a side effect the CMakeLists.txt files have become more compact. Under Windows the msvc build is done twice in the same Build_MSVC directory, so that the subsequent custom installation commands do hopefully work. Feedback welcome.

[Rüdiger Franke]

Regarding the "small fix" 05ca4d21/OMCompiler: does anyone know why the shared libs link against libOMCppOMCFactory_static?

[Rüdiger Franke]

Everything seems to work with the regular OMCFactory, see b0a5479/OMCompiler.

[Niklas Worschech]

Hi,
with your changes the windos build is broken. I got this error measage:
# move msvc libs into subfolder
mkdir -p Build_MSVC/tmp/lib/omc/cpp/msvc
mv Build_MSVC/tmp/lib/omc/cpp/*.dll Build_MSVC/tmp/lib/omc/cpp/msvc
mv: cannot stat `Build_MSVC/tmp/lib/omc/cpp/*.dll': No such file or directory
make[2]: * [runtimeCPPmsvc] Error 1
You can also see it here:
​https://test.openmodelica.org/hudson/job/OM_Win/lastBuild/console

[Rüdiger Franke]

It looks like the "simple" solution does not work. We should then do it like under Linux:

• use Build_MSVC for the dynamic build
• use a new Build_MSVC_static for the static build

The problem is that we have no make install for the msvc build. This is why the install commands in Makefile.omdev.mingw need to be modified/extended to grab the results from the two build directories.

[Rüdiger Franke]

I don't find the error message given in comment:5 in the linked lastBuild/console output!?

[Niklas Worschech]

The error is in the build before:
​https://test.openmodelica.org/hudson/job/OM_Win/7508/consoleText
mybe the last om win build stops now because of another problem before the cpp runtime build starts

[Rüdiger Franke]

See 80dcee4/OMCompiler that implements comment:6. Let's wait for the next OM_Win test...

[Adrian Pop]

Sorry for the Windows machine being offline, I had to built v1.9.6 manually.
Now is back on and we'll see soon how the builds are going.

[Niklas Worschech]

Now I got this error Simulation stopped with error in model factory: simulation error message: Failed loading SimConroller library!D:\Projekte\OMC\OpenModelica\build\lib
omc\cpp\msvc\OMCppSimController_static.lib
Also the precompiled header does not work anymore. Can we revert your changes

[Rüdiger Franke]

Please don't revert the changes. It was a mess with all build dependencies defined twice: for static and for dynamic. I'm sure that these things can be solved. Precompiled headers should work for the dynamic runtime.

[Niklas Worschech]

Ok no problem I will not revert it. I thought the dynamic runtime is used by default.

I tested it with this call

omc +simCodeTarget=Cpp +target=msvc10 BouncingBall

[Rüdiger Franke]

I checked under Linux. Getting:

Build/LibrariesConfig.h:#define SIMCONTROLLER_LIB "libOMCppSimController.so"
Build_static/LibrariesConfig.h:#define SIMCONTROLLER_LIB "libOMCppSimController_static.a"

Something might go wrong with the installation of the msvc build. Can you try to disable the static build (comment out all Build_MSVC_static things in Makefile.omdev.mingw)?

[Rüdiger Franke]

d48d574/OMCompiler makes the target platform for the compilation of the Cpp runtime configurable. So far specify a list in the Makefile, like:

PLATFORMS=x86_64-linux-gnu i686-w64-mingw32 static dynamic

The Cpp runtime is then built for each of the specified platforms. The ability to do this might better motivate why I touched the build process at all.

Currently the PLATFORMS list has no effect on the msvc build.

@adrpo: Ideally the msvc builds might be treated as additional platforms, getting rid of all the msvc specific code in Makefile.omdev.mingw. Also the msvc subdirectories might not be placed below but besides the mingw libs -- some lib/${PLATFORM}/omc.

[Niklas Worschech]

I think it is important that we have a least one test for each commit that tests the simulation on windows with visual studio. Because it costs always a lot of time to fix the windows build and the precompiled header usage.

[Rüdiger Franke]

Currently we have

​https://test.openmodelica.org/hudson/job/OM_Win/lastBuild/console

It takes a couple of hours to see the result though. Would be great if someone who uses the Windows build environment could check interactively what exactly is going wrong.

Even better if the msvc build would share the make commands with the mingw build, in order to reduce the implementation and maintenance effort. See also my comment:15 about the installation directories of msvc libs.

[Niklas Worschech]

Linux is tested very well. But the Windows users (and Bosch Rexroth uses Windows) often have problems because the pull request will not be consider the windows usage. Afterwards it is always more difficult to find the error.

[Rüdiger Franke]

Once the Cpp runtime can be cross compiled, a few lines of code suffice for multi-platform FMUs. See 95e9b46/OMCompiler.

Let's sort out the remaining Windows issues now.

[Adrian Pop]

I fixed some of the issues with pre-compiled headers on msvc and the libraries in ModelicaLibraryConfig_msvc.inc.in

• c27405/OMCompiler
• c34119/OMCompiler
• 5c0486/OMCompiler

[Rüdiger Franke]

A couple of more commits should close Pandora's box again:

1. only build one OMCFactory lib for the dynamic runtime: 65c3669/OMCompiler
2. consistent use of respective library for dynamic linkage: 8793d23/OMCompiler
3. 88cdf8e/OMCompiler cleans up the earlier attempt dc190dc/OMCompiler and makes the OMCFactory lib always static. This should be the same as before the separation of dynamic and static build (the dynamic lib was generated but not used).

[Martin Sjölund]

Milestone deleted