Cppruntime should use Sundials from 3rdParty

[Martin Sjölund]

The C-runtime currently compiles Sundials from source and this version of sundials is shipped with OMC. However, the cppruntime uses the system version of Sundials which means that the Linux packages still depend on Sundials in order to build the deb-packages.

[Martin Sjölund]

This issue needs to be fixed. The easy fix for me (since I don't use cmake) is to remove the cppruntime from the testsuite and change the test to not fail if cppruntime fails to build, but I know people are interested in maintaining the code so it should be fixed as soon as possible.

[Rüdiger Franke]

We will investigate this asap as the new daeMode should be made available with IDA in the Cpp runtime.

[Martin Sjölund]

I should note that @wbraun chose to install the sundials library into the C-runtime directory. Perhaps a more neutral lib/x86_64/omc/sundials is desired? If the libraries are moved, make a note so I can fix the Linux nightly builds ;)

[Niklas Worschech]

one problem is in the CMakefile of cpp runtime folder. The section
#set sundials solvers include and library directories

IF(MSVC)

SET(Sundials_Path "${CMAKE_SOURCE_DIR}/../../3rdParty/sundials/build_msvc")

ELSEIF(MINGW)

SET(Sundials_Path "${CMAKE_SOURCE_DIR}/../../3rdParty/sundials/build")

ENDIF(MSVC)

has to be replaced with:

IF(MSVC)

SET(Sundials_Path "${CMAKE_SOURCE_DIR}/../../3rdParty/sundials/build_msvc")

ELSE(MSVC)

SET(Sundials_Path "${CMAKE_SOURCE_DIR}/../../3rdParty/sundials/build")

ENDIF(MSVC)

then the cpp runtime should also use sundials from the 3rdParty folder on linux

[Rüdiger Franke]

The change to CMakeLists.txt works, provided the definitions are moved out of the WIN32 section and the link path is also provided to the simulation executable. I had to uninstall the system provided Sundials though -- even when saying NO_DEFAULT_PATH!?

Replying to sjoelund.se:

I should note that @wbraun chose to install the sundials library into the C-runtime directory. Perhaps a more neutral lib/x86_64/omc/sundials is desired? If the libraries are moved, make a note so I can fix the Linux nightly builds ;)

The cleaner option might be to leave commonly used libs like Sundials in the main directory and move specific libs of the C runtime to a subdirectory lib/x86_64/omc/c.

[Martin Sjölund]

Replying to rfranke:

The change to CMakeLists.txt works, provided the definitions are moved out of the WIN32 section and the link path is also provided to the simulation executable. I had to uninstall the system provided Sundials though -- even when saying NO_DEFAULT_PATH!?

That is pretty bad. We need to create the same binaries regardless if Sundials is installed or not. The way we do it for the C-runtime is to set the rpath (this changes the search order). But actually looking at the libraries, the OM-provided sundials links against the system KLU, AMD, BTF, libsuitesparseconfig which is also not great and should be fixed. -Wl,-rpath=/install/path -Wl,-rpath-link=/build/path might help (keep in mind the OM build directory is not the install path; for OSX the install name for colamd, etc probably also needs to be fixed).

The cleaner option might be to leave commonly used libs like Sundials in the main directory and move specific libs of the C runtime to a subdirectory lib/x86_64/omc/c.

This leads to quite a lot more rpaths that need to be set for the run-time, but yes it could be an option.

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

[Martin Sjölund]

This has now been resolved.