#3465 closed defect (fixed)
Hudson fails with test Crane_FMU1_CPP
Reported by: | Rüdiger Franke | Owned by: | Adrian Pop |
---|---|---|---|
Priority: | high | Milestone: | 1.9.4 |
Component: | Testing Framework | Version: | |
Keywords: | Cc: | Marcus Walther, sjoelund |
Description
Hudson produced twice the following error message that is hardly related my change on records (jobs 787, 788):
messages = "Simulation execution failed for model: cranes_crane_me_FMU module = FMICAPI, log level = FATAL: Could not load the DLL: /var/lib/hudson/slave/workspace/OpenModelica_TEST_PULL_REQUEST/OpenModelica/testsuite/openmodelica/cppruntime/fmu/modelExchange/1.0/Crane_FMU1_CPP.mos_temp3254/binaries/linux64/cranes_crane.so: undefined symbol: _ZN13StatArrayDim2IdLm3ELm3ELb0EEclEmm
c++filt -n:
StatArrayDim2<double, 3ul, 3ul, false>::operator()(unsigned long, unsigned long)
The operator()(size_t, size_t) finds in the file Array.h. The test succeeds on my development machine.
I disabled it temporarily and added an alternative simple FMI 1.0 test.
Change History (7)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
The issue is really strange. It occurs in the functions-class of the model. In more detail it occurs inside the function "Modelica_Mechanics_MultiBody_Frames_resolve2", which uses a reference to a custom type that contains the array-class.
The strange thing is that this function is never called and the custom type is not used. This seems to produce some trouble. If I add a line to the model class to create an instance of the custom type, the error disappears.
comment:3 by , 9 years ago
We now create a dummy variable for each custom type which is defined in the function-class (see OMCompiler - 2fa610a1e). This happens during initialization and will fix the linker error. The crane models are part of the testsuite again. The pull request job including the changes (829) succeeded, so I think we can close the ticket.
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:5 by , 9 years ago
Milestone: | Future → 1.9.4 |
---|
Sorting these closed tickets away from "Future". Since they were closed after the last 1.9.3 release, it's very likely that they should have been part of the 1.9.4 release.
A similar error occurs with MinGW as well, so it seems to be a GCC 4.4 related issue.