Support multi-platform FMUs from OMEdit

[Rüdiger Franke]

A couple of months ago the command buildModelFMU was extended with a list of platforms. See Martin's presentation at the OpenModelica workshop:

buildModelFMU(FmuExportCrossCompile, version = "2.0",
  fmuType = "me_cs", platforms = {
    // Requires osxcross manually installed
    "i386-apple-darwin15",
    "x86_64-apple-darwin15",
    // apt-get install gcc-arm-linux-gnueabihf
    "arm-linux-gnueabihf",
    "x86_64-linux-gnu",
    // apt-get install libc6-dev : i386
    "i686-linux-gnu",
    // apt-get install gcc-mingw-w64-x86-64
    "x86_64-w64-mingw32",
    // apt-get install gcc-mingw-w64-i686
    "i686-w64-mingw32"
  });

This works for the C and the Cpp runtime by now. OMEdit should allow to configure target platforms for FMI export. In the simplest case by manually entering a list of platforms in a text field under

Tools->Options->FMI

[Martin Sjölund]

It should be possible to create a list by searching for programs in the PATH matching [a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[g]cc, or possibly looking at /usr/lib/ or /usr/include dirs as a simple step helping the user.

[Rüdiger Franke]

This would of course be better.

cd /usr/bin; ls [a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[g]cc

gives for instance:

i686-w64-mingw32-gcc  x86_64-linux-gnu-gcc

This could be used to generate a list of check boxes:

• Tools
  • Options/FMI/Platforms
    • i686-w64-mingw32
    • x86_64-linux-gnu

The labels of the selected boxes would be passed as platforms to buildModelFMU. If nothing is selected (default setting) then no platforms are passed to buildModelFMU, resulting in an FMU for the native platform.

[Rüdiger Franke]

In the case of Cpp, one has to cross compile the runtime first. It will be installed besides the regular omc libs. In the example of comment:2 we have:

$OMHOME/lib/i686-w64-mingw32/omc
$OMHOME/lib/x86_64-linux-gnu/omc

If the C runtime would also precompile runtime libs, then this information could be used to generate a list of platforms independently of the compiler name.

Ultimately the Windows build might also use such a directory structure, e.g. having something like:

$OMHOME/lib/arm-microsoft-wince/omc
$OMHOME/lib/i386-microsoft-win32/omc
$OMHOME/lib/x86_64-microsoft-win32/omc
$OMHOME/lib/x86_64-w64-mingw32/omc

(the last directory for the default gcc compiler shipping with OpenModelica, gcc -dumpmachine)

[Adeel Asghar]

Added support for it in cd92453/OMEdit.

[Rüdiger Franke]

I'm getting the error message:

/bin/sh: 1: i686-w64-mingw32-gcc-g++: not found

Can you strip the compiler suffix -gcc from the platform names?

[Adeel Asghar]

When are you getting this error? When you try to export FMU or just when displaying list of platforms in Options->Tools->FMI?

[Rüdiger Franke]

I'm getting this error when compiling an FMU, because the *_FMU.makefile appends -g++ to the platform triplet. Also OMEdit should just show i686-w64-mingw32 instead of i686-w64-mingw32-gcc.

[Adeel Asghar]

I guess we should update the regular expression to [a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[g] or should have two different filters one for gcc and one for g++ i.e.,

• [a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[g]cc
• [a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[g]++

Removing -gcc might result in output of irrelevant strings.

Also I think we should include QDir::Executable filter in the call to ​QDir::entryList.

[Martin Sjölund]

I don't think g++ is necessary to look for (it's almost always a symlink to the corresponding gcc). rfranke is correct i686-w64-mingw32 instead of i686-w64-mingw32-gcc.

If you use QDir::Executable, make sure that you still find symbolic links (most gcc versions point somewhere else).

[Adeel Asghar]

but don't you think [a-zA-Z0-9_-]*-[a-zA-Z0-9_-]*-[a-zA-Z0-9_-]* will output irrelevant files as well.

[Rüdiger Franke]

This pull request does what I meant:

​https://github.com/OpenModelica/OMEdit/pull/13

[Rüdiger Franke]

Just created first cross-compiled and multi-platform FMUs from OMEdit :-)

Btw. the Cpp runtime does always creates a static FMU. This is because FMUs are intended to be exported to other machines and to survive version changes of the exporting tool. With dynamic FMUs I encountered the problem that after a couple of weeks the dynamic FMU crashed even on the same machine, because something had changed in a linked runtime lib, no matter if generated with C or Cpp runtime.

This is why the default linkage should not be "dynamic" but "static".

[Adeel Asghar]

Made "static" the default linkage in 4bcfe5e/OMEdit. I am sure Martin will not be happy with that but I think it doesn't matter since you can set your preferred linkage in OMEdit's settings.

[Martin Sjölund]

I am happy with that. There is a reason I pushed for statically linked FMUs...

[Martin Sjölund]

The only problem is co-simulation does not support it, I think.

[Rüdiger Franke]

This pull request should finally do it for clang and gcc:

​https://github.com/OpenModelica/OMEdit/pull/14

Regarding static linking: we must find a compromise under Linux. The system libs can only be linked dynamically, e.g. -static-libgcc does not work for a shared lib. But they are rather stable and care about versions. The OpenModelica runtime libs on the other side may change on a daily basis -- they should really be linked statically. Other libs, like expat, sundials, lapack, etc. are somewhere in between.

[Martin Sjölund]

Milestone deleted