OpenModelica
Can't generate crossbuild FMU with CVODE on Windows
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 https://github.com/OpenModelica/OpenModelica/issues/10174#issuecomment-2317339458
Ref to the upstream (crossbuild) update request: https://github.com/multiarch/crossbuild/pull/61. I don't think this will be updated any time soon, judging from the activity level on that repo.
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.
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...
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:\...) 🤷
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
@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.
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…
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.
@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 (https://github.com/multiarch/crossbuild/pull/61) one possibility would be to update the crossbuild Docker image and host in in the Openmodelica Dockerhub org, maybe?
@casella any chance you guys can take a look at unbreaking the multi-platform FMU export from OMEdit?
I try to create a new (or updated) version of a cross-compilation image for our FMUs and will add it to our OpenModelica Docker hub. I'll add a new repo for this, similar to https://github.com/OpenModelica/build-deps.
Off-topic: All I wanted to do was fixing a tiny memory leak. One line of code, in and out in 5 minutes. Now I'm 5 PRs deeper and need to create a completely new repo 😆
- Fixing a crash in a FMU: Oh this is a memory leak
- Fixing memory Leak: Oh Valgrind reports aren't any good, because we include C files into C files
- Compile single FMU C files: Oh I don't want to port my changes to the deprecated FMU Makefile builds
- Removing FMU Makefile buils: Oh the CMake version is too old to cross-compile in this image
- Updating CMake: Oh the docke rimages are so old we need to crate new ones
- New cross-compile docker image
- Updating CMake: Oh the docke rimages are so old we need to crate new ones
- Removing FMU Makefile buils: Oh the CMake version is too old to cross-compile in this image
- Compile single FMU C files: Oh I don't want to port my changes to the deprecated FMU Makefile builds
- Fixing memory Leak: Oh Valgrind reports aren't any good, because we include C files into C files
I try to create a new (or updated) version of a cross-compilation image for our FMUs and will add it to our OpenModelica Docker hub. I'll add a new repo for this, similar to https://github.com/OpenModelica/build-deps.
❤️
Off-topic: All I wanted to do was fixing a tiny memory leak. One line of code, in and out in 5 minutes. Now I'm 5 PRs deeper and need to create a completely new repo 😆
* Fixing a crash in a FMU: Oh this is a memory leak * Fixing memory Leak: Oh Valgrind reports aren't any good, because we include C files into C files * Compile single FMU C files: Oh I don't want to port my changes to the deprecated FMU Makefile builds * Removing FMU Makefile buils: Oh the CMake version is too old to cross-compile in this image * Updating CMake: Oh the docke rimages are so old we need to crate new ones * New cross-compile docker image
Believe me, I know the feeling! 😅 Try to keep in mind that your efforts now clean up 4-6 issues in one go! Teh progress! :D
Now we have a first version of an OpenModelica managed cross build image: https://github.com/OpenModelica/openmodelica-crossbuild
We don't support macOS, since XCode and cross compiling for Apple is on shaky legal ground and I don't think there are any official Ubuntu packages with cross compilers for exactly this reason.
I'll see if I can update the compiler to verify the signature of the docker image before running it. I added CMake tool chain files to the image. So the compiler needs to add the right one when compiling.
External C code is a real nightmare. Collecting runtime dependencies with CMake isn't supported when cross compiling. And I don't think we have a way to add some arbitrary C project to our FMUs.