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

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

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

-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.

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  . 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.

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!

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

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

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.

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.