Can't generate crossbuild FMU with CVODE on Windows

[bilderbuchi]

Another "fun" aspect concerning the FMU out-of-the-box experience (#10174) is that the crossbuild image is based on such an old Debian that it ships an ancient CMake, with the consequence of clashing with current default flags

CMake Error at CMakeLists.txt:31 (message):
--fmuRuntimeDepends=modelica requires CMake version 3.21 or higher. You are running version 3.7.2. Use OpenModelica compiler flag '--fmuRuntimeDepends=none' to disable

Frustratingly, using --fmuRuntimeDepends=none as a workaround recommended by the docs causes a subsequent failure

CVODE_DIRECTORY: C:/OpenModelica1.24.0-dev-64bit/lib/x86_64-linux-gnu/omc
CMake Error at CMakeLists.txt:162 (message):
Couldn't find library sundials_cvode in
C:/OpenModelica1.24.0-dev-64bit/lib/x86_64-linux-gnu/omc
-- Configuring incomplete, errors occurred!

Which is no surprise, I guess, because we had to not include runtime dependencies!

In effect, I can't see a way to compile a Linux FMU (e.g. for use in a Docker container) from Windows, while avoiding the Euler solver.

How to work around that? Find another appropriate image with newer versions somehow? Is something that could be used instead of multiarch/crossbuild hosted on the OM docker repo?
@AnHeuermann, any ideas?

Originally posted by @bilderbuchi in #10174 (comment)

[bilderbuchi]

Ref to the upstream (crossbuild) update request: multiarch/crossbuild#61. I don't think this will be updated any time soon, judging from the activity level on that repo.

[bilderbuchi]

CVODE_DIRECTORY: C:/OpenModelica1.24.0-dev-64bit/lib/x86_64-linux-gnu/omc

Which is no surprise, I guess, because we had to not include runtime dependencies!

Is maybe some path machinery going wrong here? That CVODE_DIRECTORY path does not exist on my machine, but C:\OpenModelica1.24.0-dev-64bit\lib\omc (i.e. without the arch triplet) does exist, and contains sundials libraries.

[casella]

@adrpo could you please take care of that?

[sevoigt]

Seems to be an issue with cmake and how the path to the sundials lib is assembled. Just had a similar issue on Fedora 41. The CMakeLists to build the fmu contains

`set(CVODE_DIRECTORY

"/opt/openmodelica-nightly/bin/../lib/${CMAKE_LIBRARY_ARCHITECTURE}/omc"`

CMAKE_LIBRARY_ARCHITECTURE is the problem here. On may machine it returns "x86_64-redhat-linux-gnu", whereas the omc directory is just "x86_64-linux-gnu". I created a symlink and it works fine.

Why not just hardcode the lib-paths for win and linux? You'll never know what cmake comes up with on any OS...

[bilderbuchi]

You'll never know what cmake comes up with on any OS...

It seems like it's actually the compiler that CMake gets differing folder names from, and not an issue with CMake? Presumably on your Redhat the location of that "system library search directory" is different?

Target architecture library directory name detected for <LANG>.

If the <LANG> compiler passes to the linker an architecture-specific system library search directory such as <prefix>/lib/<arch> this variable contains the <arch> name if/as detected by CMake.

https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LIBRARY_ARCHITECTURE.html#variable:CMAKE_%3CLANG%3E_LIBRARY_ARCHITECTURE

Why not just hardcode the lib-paths for win and linux? You'll never know what cmake comes up with on any OS...

I'm not sure if that would solve the original problem, though: this inserts a Linux arch string (x86_64-linux-gnu) on a Windows machine/OM installation, and thus fails. I suspect this is because some part of the build config does not correctly account for cross-compilation? Or the cross-build Docker image erroneously being fed Windows paths (C:\...) 🤷

[sevoigt]

Ah ok, thanks for ponting that out.

I'm not sure if that would solve the original problem, though: this inserts a Linux arch string (x86_64-linux-gnu) on a Windows machine/OM installation, and thus fails.

My naive idea was not to use CMAKE_LIBRARY_ARCHITECTURE at all in the paths, so that nothing is inserted no matter if from cmake or the compiler. Just use C:/OpenModelica/lib on win and /openmodelica/lib/x86_64-linux-gnu/ on linux. But I'm certainly lacking some background here. And this would probably fail as soon as someone tries to build e.g. for arm64

[bilderbuchi]

@adrpo is there a path to fix multiplatform FMU export using CVode, with reasonable effort/time?

Right now I am exporting separate FMUs, the Windows one using the installed OMEdit, and a Linux one with a fragile stack of scripts executing an openmodelica-minimal docker container.
This is quite cumbersome/fragile, and does not get us a multiplatform FMU (but two separate files), to boot. Just copying the binaries from one to the other is insufficient as GUIDs are then wrong.

[sevoigt]

Did you try building it for Linux in WSL on Windows? This is how SimulationX does it. They just generate a makefile along with the fmu sources, build it in WSL and put the binary back in the fmu-zip.

Windows-only of course and I don‘t know if the fmu-sources generated by OpenModelica are this kind of cross platform plug&play…

[bilderbuchi]

I did not -- just opening, recompiling, repacking is an interesting approach! I'll have to check if the cmake config in the Windows FMU can deal with that.

[bilderbuchi]

@adrpo is there something I can do on my side to troubleshoot/diagnose this to aid in fixing the problem?

As it seems an upstream update won't be coming (multiarch/crossbuild#61) one possibility would be to update the crossbuild Docker image and host in in the Openmodelica Dockerhub org, maybe?

[bilderbuchi]

@casella any chance you guys can take a look at unbreaking the multi-platform FMU export from OMEdit?

[casella]

@adrpo, @arun3688, what do you think?