Wrong link order of Libraries used by Modelica.Blocks.Tables

[rfranke]

Modelica.Blocks.Tables.CombiTable{1D,1Ds,2D} contain external function calls and

annotation (Library={"ModelicaStandardTables", "ModelicaMatIO", "zlib"});

This is the wrong link order, because ModelicaMatIO uses functions of ModelicaStandardTables (Mat_Open, Mat_VarReadInfo, ...).

The annotation should be:

annotation (Library={"ModelicaMatIO", "ModelicaStandardTables", "zlib"});

The problem can be reproduced with OpenModelica's FMI export under Windows using a model like

model TableTest
  extends Modelica.Blocks.Tables.CombiTable2D(
      table = [0.0,   1.0,   2.0,   3.0;
               1.0,   1.0,   3.0,   5.0;
               2.0,   2.0,   4.0,   6.0]);
  annotation(uses(Modelica(version="3.2.2")));
end TableTest;

OpenModelica contains MinGW. FMI export shall produce a dll that contains all external dependencies. Using the bundled g++ version 5.3.0, the linker call is as follows,

g++ -shared -o TableTest.dll OMCppTableTestCalcHelperMain.o ... -Wl,--no-undefined ...\
    -lModelicaStandardTables -lModelicaIO -lModelicaMatIO -lzlib ... -static

This produces the error:

C:/OpenModelica1.13.0-dev-32bit//lib//omc\libModelicaIO.a(ModelicaIO.o): In function `readMatIO':
C:\dev\OpenModelica32bit\OMCompiler\3rdParty\ModelicaExternalC\BuildProjects\autotools/../../C-Sources/ModelicaIO.c:446: undefined reference to `Mat_Open'
...
collect2.exe: error: ld returned 1 exit status
TableTest_FMU.makefile:93: recipe for target 'TableTest.fmu' failed
make: *** [TableTest.fmu] Error 1

The problem is worked around in the current nightly build of OpenModelica by linking ModelicaStandardTables a second time after the model defined external libs, see:

OpenModelica/OMCompiler@cacc8bf

It should be solved by changing the order of libraries in Modelica.Blocks.Tables.*.

[beutlich]

This is the wrong link order, because ModelicaMatIO uses functions of ModelicaStandardTables (Mat_Open, Mat_VarReadInfo, ...).

Hm, Mat_Open and Mat_VarReadInfo are declared in module ModelicaMatIO.c and utilized by module ModelicaStandardTables.c. Thus, the other way round.

Can you check the OMC linking again with current master, especially after my 11.5 months old commit 7ac5e51 for #2192?

[beutlich]

I also wonder why OMC reports this linking error right now, after I added it more than 2 years ago (see f9a30ca for #1856).

[sjoelund]

I suppose because we mostly test OpenModelica on Linux which uses dynamic linking, and there all so-files are already linked against their respective symbols.

[rfranke]

Hm, Mat_Open and Mat_VarReadInfo are declared in module ModelicaMatIO.c and utilized by module ModelicaStandardTables.c. Thus, the other way round.

If the functions are defined in ModelicaMatIO and utilized by ModelicaStandardTables, then the annotation should indeed be changed to:

annotation (Library={"ModelicaMatIO", "ModelicaStandardTables", "zlib"});

[sjoelund]

If they are defined in ModelicaMatIO but used by Tables, Tables should be before on the list, just like zlib is last because the functions are defined in zlib and used by ModelicaMatIO.

[rfranke]

Yes, you are right, sorry.

This would mean that OpenModelica messes up C source names and libarary names, because libModelicaMatIO does not have the functions (link order -lModelicaStandardTables -lModelicaMatIO):

C:/OpenModelica1.13.0-dev-32bit//lib//omc/cpp\libModelicaMatIO.a(ModelicaIO.c.obj):ModelicaIO.c:(.text+0xf0): undefined reference to `Mat_Open'
C:/OpenModelica1.13.0-dev-32bit//lib//omc/cpp\libModelicaMatIO.a(ModelicaIO.c.obj):ModelicaIO.c:(.text+0x120): undefined reference to `Mat_VarReadInfo'

The linker error disappears with reversed link order -lModelicaMatIO -lModelicaStandardTables.

[sjoelund]

I would suggest trying to compile with the actual libraries generated by the ModelicaExternalC project instead of the custom CMakeLists.txt used by the Cppruntime. ModelicaIO doesn't seem to have its own library there which is sure to cause some problems. The ModelicaMatIO.a only contains ModelicaIO.c as well... Just crazy.

[beutlich]

OK, closing as invalid then.

[rfranke]

Sorry for having spammed this tracker with OpenModelica issues. I couldn't imagine that sources and libraries would flip names. The following commit should clean it up: OpenModelica/OMCompiler@9062175