-
Notifications
You must be signed in to change notification settings - Fork 316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't generate crossbuild FMU with CVODE on Windows #12855
Comments
Ref to the upstream ( |
Is maybe some path machinery going wrong here? That |
@adrpo could you please take care of that? |
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... |
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?
I'm not sure if that would solve the original problem, though: this inserts a Linux arch string ( |
Ah ok, thanks for ponting that out.
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 |
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 flagsFrustratingly, using
--fmuRuntimeDepends=none
as a workaround recommended by the docs causes a subsequent failureWhich 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)
The text was updated successfully, but these errors were encountered: