Make sure you don't have local changes; do make clean or svn-clean. Hudson says that revision works just fine: https://test.openmodelica.org/hudson/jo … UILD/4962/

Thanks for the tip.  Make clean did fix the problem. But I have not made any changes to code
except changing the rml library. (I did run ldconfig after that)


But now I have problem with DASSL solvers. I can run example files successfully with all other solvers excepting the
DASSL solvers.  I get the following error with simulate command.



LOG_SOLVER        | info    | Start numerical solver from 0 to 1
LOG_SOLVER        | info    | call solver from 0 to 0.002 (stepSize: 0.002)
LOG_DDASRT        | info    | Calling DDASRT from 0 to 0.002
LOG_SOLVER        | info    | | Start step 0 to 0.002
DASSL--  SOME ELEMENT OF INFO VECTOR IS NOT ZERO OR ONE
stdout            | warning | The code has encountered trouble from which it cannot recover.
stdout            | warning | can't continue. time = 0.000000


My first attempt to use Modelica 1.8 had similar issue and I posted the debug log then. I gave up after struggling to
find the root cause of it. Now even with Modelica 1.9  the issue persists. At least this time I have a bit more sensible
log description. Any suggestion as to where my problem could lie???

Maybe fedora includes a version of LAPACK that does not work the same way as the one we use?

liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f243913e000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f2438e9d000)

I have explore this further. The trouble seems to be that   after info array is passed to the _dassrt routine, the contents of that array are different to that
the GUI function passes to it.   

In
RuntimeSimulation om/SimulationRuntime/c/simulation/solverdssl.c   
   I checked the values of  "info"  vector   in the  dasrt_step function. And they are 15 values are legitimate [ 0 or 1]
But when the function call DDASRT (alias _dassrt)  is made,

in the called function the passed pointer address is correct. But the vector
although correct up to some values, spurious numbers  { eg. info[10] = 33 }
( I put some debug statements in  /SimulationRuntime/c/math-support/ddasrt.c file
  at the start of the _dassrt  function call.  I am aware that the function rolls back the pointer by one count (fortran array indexing stuff I think)
So I print the values after the pointer is decremented)

I have no f2c installed on my computer. Include and library files are generated from the source provided in the trunk.
Is there an issue with f2c and gcc  .....

In short I don't believe the problem is the Blas or Lapack since we have not yet begun to initialize the solver ....

My suspicion is that somehow the info vector is getting corrupted when called by (f2c translated function)

Let me know what your thoughts are

I finally figured this out. The problem was the f2c source tree. Its include files are configured for 32 bit machine. Replaced "long int" to "int"
as suggested in f2c README. Things worked fine from then on.

Hope this helps others who had similar issue. Hopefully, this f2c header files are modified to make sure this need not be done by the user compiling from the source.