Linking of simulation code broken in Linux

[Francesco Casella]

After updating to this early morning's nightly (dev-533-ga85e5c7), we haven't been able to compile and simulate our test cases under Linux, due to library issues with the linker, even if we don't use the IDA solver at all.

Excerpt from the compilation log:

clang -I. -o UCTE_RETE_C_v3_nsl_m1__LoadPQ UCTE_RETE_C_v3_nsl_m1__LoadPQ.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_functions.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_records.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_01exo.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_02nls.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_03lsy.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_04set.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_05evt.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_06inz.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_07dly.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_08bnd.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_09alg.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_10asr.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_11mix.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_12jac.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_13opt.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_14lnz.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_15syn.o UCTE_RETE_C_v3_nsl_m1__LoadPQ_16dae.o -I"/usr/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -L"/home/casella/dynamica/OMC_RUN/2016.05.03_2" -fPIC -O0 -falign-functions -march=native -I"/usr/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -L"/home/casella/dynamica/OMC_RUN/2016.05.03_2" -L"/usr/lib/x86_64-linux-gnu/omc" -L"/usr/lib" -Wl,-rpath,"/usr/lib/x86_64-linux-gnu/omc" -Wl,-rpath,"/usr/lib" -lSimulationRuntimeC -llapack -lblas -lm -lm -lomcgc -lpthread -rdynamic -Wl,--no-undefined
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `SlsConvertDls'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `NewSparseMat'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `PrintSparseMat'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `SlsAddMat'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `IDASlsGetNumJacEvals'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `IDAKLU'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `DestroySparseMat'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `IDASlsSetSparseJacFn'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `CopySparseMat'
/usr/lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so: undefined reference to `SlsSetToZero'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[Willi Braun]

Martin, do you know, where I forgot to add our own 3rdParty sundials version?
Also why do it work on hudson, but not in that build?

[Adrian Pop]

As far as I know we don't build our own sundials on Linux, only in Windows.

[Willi Braun]

I hope to change that in ​https://github.com/OpenModelica/OMCompiler/pull/802.

[Martin Sjölund]

You did not add the sundials libraries to the Linux installer: ​https://github.com/OpenModelica/OpenModelicaBuildScripts/tree/master/debian which causes the system Sundials to be used since /usr/lib is also searched for libraries.

[Martin Sjölund]

By the way, since we compile sundials ourselves, should it be removed from configure? Otherwise, Sundials is only used if it is installed on the OS although we don't use that part?

[Willi Braun]

Replying to sjoelund.se:

You did not add the sundials libraries to the Linux installer: ​https://github.com/OpenModelica/OpenModelicaBuildScripts/tree/master/debian which causes the system Sundials to be used since /usr/lib is also searched for libraries.

Ah, I see. Thanks.

Do we need to rename the libraries, to not coming in conflict with the installed one?
Also the the CPP runtime use these own libraries, so we could use the same, but currently we them twice in the lib path. So is there a directory where we can put shared libraries?

[Martin Sjölund]

It is good to rename the libraries like we do for libgc, but they do not conflict with the system libraries since we install to /usr/lib/x86_64-gnu-linux/omc/, which is shared between the C and C++ runtime.

[Francesco Casella]

After upgrading some dependencies manually via apt-get, I can now compile simulation executable in Linux again. So, I'm closing the ticket.

[Francesco Casella]

In fact, I can compile and run simulations from the command line, but not from OMEdit. Any clue?

[pierre.haessig@…]

I got the same errors (undefined reference to `SlsConvertDls' [...]) using nightly version 1.10.0~dev-601-gfdba0f8 on Debian testing (stretch) with the jessie channel. Is this related to my specific Linux system or just the bug is not yet fixed for all Linux distributions?

[Willi Braun]

Replying to pierre.haessig@…:

I got the same errors (undefined reference to `SlsConvertDls' [...]) using nightly version 1.10.0~dev-601-gfdba0f8 on Debian testing (stretch) with the jessie channel. Is this related to my specific Linux system or just the bug is not yet fixed for all Linux distributions?

For me the nightly build 1.10.0~dev-601 seems to work, but for some reason I have to update the libomcsimulation manually, after update of omc.

[Francesco Casella]

Replying to wbraun:

For me the nightly build 1.10.0~dev-601 seems to work, but for some reason I have to update the libomcsimulation manually, after update of omc.

How do you do that? If I try to run apt-get update/upgrade, I'm told that everything is up-to-date and there is nothing to update.

[Willi Braun]

Replying to casella:

Replying to wbraun:

For me the nightly build 1.10.0~dev-601 seems to work, but for some reason I have to update the libomcsimulation manually, after update of omc.

How do you do that? If I try to run apt-get update/upgrade, I'm told that everything is up-to-date and there is nothing to update.

With apt-get update/upgrade it should work. When I checked that on my machine I did just apt-get update and apt-get install omc(since didn't wanted to upgrade the whole system.), but then I need also update "apt-get install libomc libomcsimulation".

[Francesco Casella]

Replying to wbraun:

With apt-get update/upgrade it should work.

Unfortunately it doesn't

When I checked that on my machine I did just apt-get update and apt-get install omc(since didn't wanted to upgrade the whole system.), but then I need also update "apt-get install libomc libomcsimulation".

I ran apt-get install libomc libomcsimulation and I got

libomc is already the newest version (1.10.0~dev-601-gfdba0f8-1).
libomcsimulation is already the newest version (1.10.0~dev-601-gfdba0f8-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

If I try to simulate Modelica.Blocks.Examples.Filter, I still get the linker errors. I don't if I simulate a simple model like this:

model foobar
  Real x(fixed = true);
equation
  der(x)  = 1-x;
end foobar;

Any clue?

[Martin Sjölund]

After looking closer, the command-line used by OMEdit contains:

"-L/usr/lib/" -Wl,-rpath="/usr/lib/" "-L/usr/lib/x86_64-linux-gnu/omc" -Wl,-rpath="/usr/lib/x86_64-linux-gnu/omc" "-L/home/marsj/.openmodelica/binaries/Modelica" -Wl,-rpath="/home/marsj/.openmodelica/binaries/Modelica" "-L/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library/x86_64-linux" -Wl,-rpath="/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library/x86_64-linux" "-L/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library/linux64" -Wl,-rpath="/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library/linux64" "-L/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library" -Wl,-rpath="/usr/lib/omlibrary/Modelica 3.2.2/Resources/Library"

Which means /usr/lib has preference over /usr/lib/x86_64-linux-gnu/omc. If you have the Ubuntu sundials installed, you would try to link against a different ABI.

[Martin Sjölund]

I'm trying to fix this in ​PR:860

[Willi Braun]

Replying to casella:

Replying to wbraun:

With apt-get update/upgrade it should work.

Unfortunately it doesn't

When I checked that on my machine I did just apt-get update and apt-get install omc(since didn't wanted to upgrade the whole system.), but then I need also update "apt-get install libomc libomcsimulation".

I ran apt-get install libomc libomcsimulation and I got

libomc is already the newest version (1.10.0~dev-601-gfdba0f8-1).
libomcsimulation is already the newest version (1.10.0~dev-601-gfdba0f8-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

If I try to simulate Modelica.Blocks.Examples.Filter, I still get the linker errors. I don't if I simulate a simple model like this:

model foobar
  Real x(fixed = true);
equation
  der(x)  = 1-x;
end foobar;

I can also confirm that, yesterday, I tested just with a simple model.

Now the difference is:
from Makefile of the simple model:

LDFLAGS= -L"/usr/lib/x86_64-linux-gnu/omc" -L"/usr/lib" -Wl,-rpath,"/usr/lib/x86_64-linux-gnu/omc" -Wl,-rpath,"/usr/lib" -lSimulationRuntimeC -llapack -lblas -lm -lm -lomcgc -lpthread -rdynamic -Wl,--no-undefined

from Makefile of the msl model:

LDFLAGS=-L"/usr/lib/omlibrary/Modelica 3.2.1/Blocks" -L"/usr/lib/x86_64-linux-gnu/omc" -L"/usr/lib" -Wl,-rpath,"/usr/lib/x86_64-linux-gnu/omc" -Wl,-rpath,"/usr/lib" -lSimulationRuntimeC -llapack -lblas -lm -lm -lomcgc -lpthread -rdynamic -Wl,--no-undefined

So the order of -L"/usr/lib/x86_64-linux-gnu/omc" and -L"/usr/lib" has changed.

[Francesco Casella]

Replying to sjoelund.se:

I'm trying to fix this in ​PR:860

I have installed the new nightly and it wow works fine. Ticket closed.

[Pierre Haessig <pierre.haessig@…>]

Same for me, using compiler 1.10.0~dev-622-g41a11e9, the Modelica.Fluid.Examples.PumpingSystem does compile and simulate (with some warnings, but that's another story).
Thanks for fixing the bug!

[Martin Sjölund]

Milestone deleted