Opened 8 years ago

Closed 6 years ago

#3933 closed defect (fixed)

Cppruntime should use Sundials from 3rdParty

Reported by: sjoelund.se Owned by: somebody
Priority: critical Milestone: 1.13.0
Component: Cpp Run-time Version: v1.10.0-dev-nightly
Keywords: Cc: wbraun, openmodelicadevelopers@…

Description

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.

Change History (10)

comment:1 Changed 8 years ago by sjoelund.se

  • Cc openmodelicadevelopers@… added
  • Version set to v1.10.0-dev-nightly

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.

comment:2 Changed 8 years ago by rfranke

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

comment:3 follow-up: Changed 8 years ago by 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 ;)

comment:4 Changed 8 years ago by niklwors

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

comment:5 in reply to: ↑ 3 ; follow-up: Changed 8 years ago by 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!?

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.

comment:6 in reply to: ↑ 5 Changed 8 years ago by sjoelund.se

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.

comment:7 Changed 7 years ago by sjoelund.se

  • Milestone changed from 1.10.0 to 1.11.0

Ticket retargeted after milestone closed

comment:8 Changed 7 years ago by sjoelund.se

  • Milestone changed from 1.11.0 to 1.12.0

Milestone moved to 1.12.0 due to 1.11.0 already being released.

comment:9 Changed 7 years ago by casella

  • Milestone changed from 1.12.0 to Future

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.

comment:10 Changed 6 years ago by sjoelund.se

  • Milestone changed from Future to 1.13.0
  • Resolution set to fixed
  • Status changed from new to closed

This has now been resolved.

Note: See TracTickets for help on using tickets.