Archived OpenModelica forums. Posting is disabled.

Alternative forums include GitHub discussions or StackOverflow (make sure to read the Stack Overflow rules; you need to have well-formed questions)


Forgot password? | Forgot username? | Register

Link to FMU models

Link to FMU models

Even if the behaviour of buildModelFMU and translateModelFMU is quite unexpected, as I mentioned here, I'm trying to use their output with my C code.

buildModelFMU (and translateModelFMU) gives these relevant files (suppose to have model.mo as main model file)
- binaries/win64/model.dll <-- the shared library
- binaries/win64/model.lib <-- the import library, I suppose
and the sources\include folder and subfolders.

Everything seems to work just fine, but the problems rise when I try to link such libraries:
the symbols of the import library DO NOT MATCH those of the shared library, resulting in a lot of linking errors like the following:
"unresolved external symbol fmi2Instantiate ..."
That's because the symbols defined the DLL (as dumpbin reports) and in the include/fmi2 header files (such as fmi2Instantiate), cannot be found in the relative import library or in any header file either.

In the DLL, there are symbols like:
...
fmi2Instantiate
fmi2SetReal
fmi2DoStep
...
and they should be correct, as indicated by the FMIstandards. They are not preceded by "<modelname>_" since they are in a shared library (as specified at the bottom of page 14 of the FMI standard v2.0).

However in the LIB, the symbols are like:
...
<modelname>_fmiInstantiate
<modelname>_fmiSetReal
<modelname>_fmiDoStep
...
like it was a real static library, not an import library and in any case I do not have any header with these declarations!.
And moreover, also if that was a real static library, the naming is wrong/old: from April 9th 2014, it should be at most <modelname>_fmi2Instantiate, with the '2'!
And also, the library file size (39KB) clearly indicates that it is not a static library!

Can anyone clarify the situation here?
How can I link to these FMU libraries? Is a run-time dynamic linking required?

Using OpenModelica Compiler v1.13.0-dev-335-gfe5c35d (64-bit)

Edited by: DarioMangoni - Jan-11-18 13:18:42

Re: Link to FMU models

Solution found, I hope.

Inside the unzipped FMU folder, under binaries/win64 a wrong import library was created.

That is probably because of the missing flag that outputs the .def file required (as you may see in the sources/Makefile) by dlltool during the generation of the binaries.

I solved adding to the CPPFLAGS the corresponding flag -Wl,--output-def=<modelname>.def

Now things are working fine.
I opened a ticket: issue 4707

We are going to discover if the problem is real and the solution is right

Edited by: DarioMangoni - Jan-12-18 14:24:27

Re: Link to FMU models

Hallo,

i'm trying to build an application for a real-time hardware with dSpace and had error messages like

dsfmu_mdlfunctions.o86: In function `HiL_TechDay_Beispiel_DSFMUInitMdl':
dsfmu_mdlfunctions.cpp:(.text+0x3e): undefined reference to `HiL_TechDay_Beispiel_fmi2Instantiate'

i thought your solution could help. my question is, where did you put the flag  -Wl,--output-def=<modelname>.def ?

is it when you export the fmu model from modelica?

i know its an old post, maybe someone could shed a light on my problem and where i've done wrong

Re: Link to FMU models

Hi,
first of all: are you sure that your program is actually linking the FMU? Did you put the correct linking options in the linker command line?
If so, here is the workaround.

Once the FMU is generated, unzip the FMU with a zip manager, go to sources, open Makefile with a text editor, you fill find the variable CPPFLAGS;
to this variable add

Code:

-Wl,--output-def=<modelname>.def

Once you have done this, save the file, open your MinGW command prompt and navigate to the sources folder and run make.
You will find your updated libraries in the binaries folder.

Now: you may want to use your own MinGW/MSYS compiler or the one included in OpenModelica: in this latter case you may hit some problems, but you will found workarounds on the web.

Re: Link to FMU models

Hallo,
thank you for you answer.

DarioMangoni wrote:


first of all: are you sure that your program is actually linking the FMU? Did you put the correct linking options in the linker command line?

could you elaborate more on that? I'm not too familiar with the linker for compilation in c/cpp  current/big_smile . The problem is, the only options available are  for me to include add certain search path for the custom source code and library (in this case the Model.fmu\source\include and Model.fmu\source\lnclude\fmi2) or to put a c/c++ compiler options (i assume this is where a put the linker flags).

i've tried to used -L<dllpath> and -lModel.dll but it keep resulting the same error.

Re: Link to FMU models

Well, it depends on which compiler you are using and the platform as well, but in general, if you have shared libraries (DLL in Win, SO in Linux) you have to decide which kind of linking you want. In Win the two type of shared library linking are called implicit and explicit.
Here is a good starting point (even if it is a little overwhelming...) Link an executable to a DLL.


You HAVE to link explicitely i.e. link during execution. Do not use implicit linking.
Ther reasons why you HAVE TO do explicit linking are described in my first post above here, but if you are not used to concepts such as import libraries, linking, etc... you will probably get lost.

However, this implies quite a big work on your side (you have to use LoadLibrary, GetProcAddress and so on...).

If some of the developers will reply I can be more sure than other linking options does not exist, but since there are no answers from them, I just rely on my observations.
Hope I am right!

Re: Link to FMU models

Okey, thank you for your answer and link. I try to read more about library linking.

Re: Link to FMU models

Hallo,

I've try the workaround you posted, but somehow there are no prefix <modelname>_fmi2function in the updated lib file. I ran the make command using the msys in OMEdit. I think that is my problem. any idea?

Edit:
my bad

thanks

Edited by: Arinomo23 - Feb-20-19 09:57:22

Re: Link to FMU models

Wait, for the DLL I only have no-prefixed functions; while in the LIB (import library) I DO have prefixes! You are saying exactly the opposite! Please check your statement!

The reason why you do not have prefixes

The FMI2_FUNCTION_PREFIX should be a preprocessor definition that is in charge of prefixing all the functions of the fmi in order to avoid name clashes.

In the fmi headers (specifically in fmi2Functions.h) as well as in the FMU reference you will find the following statement

   In order to have unique function names even if several FMUs
   are compiled together (e.g. for embedded systems), every "real" function name
   is constructed by prepending the function name by "FMI2_FUNCTION_PREFIX".
   Therefore, the typical usage is:

      #define FMI2_FUNCTION_PREFIX MyModel_
      #include "fmi2Functions.h"

Well, there are no defines for FMI2_FUNCTION_PREFIX anywhere in the source code or in makefiles, so I don't know how the import LIB library has that symbols.


   As a result, a function that is defined as "fmi2GetDerivatives" in this header file,
   is actually getting the name "MyModel_fmi2GetDerivatives".

   This only holds if the FMU is shipped in C source code, or is compiled in a
   static link library. For FMUs compiled in a DLL/sharedObject, the "actual" function
   names are used and "FMI2_FUNCTION_PREFIX" must not be defined.

Thus, it seems that for DLL/sharedObjects it is ok to NOT provide any prefix (however, I don't understand why in the import library - the one with LIB extension in the binary folder - there ARE symbols with that prefix though).
So, is it possible to implicitly link to such DLLs if the import library LIB has different symbols? Is there a redirection so that the DLL library can be used even if it has different symbols?
What if there are multiple FMUs: will their symbol clash?

This is still something not clear to me.

Re: Link to FMU models

By the way, here you can find my previous answer on how to link explicitely to FMUs.

Are just hints, not a full working file, but this is something to start from.

There are 0 guests and 0 other users also viewing this topic