Statically link libstdc++ on Windows

[simon.zeni@…]

Hi,

For my work I need to load an FMU in Matlab from a C++ S-Function. The FMU in question is a shared library (DLL) zipped in an archive with all the dependencies generated by the compilation.

The code is compiled from OMScript with the following line :

translateModelFMU('FMU', version="1.0")

The code generation and compilation goes without any problem. The trouble comes at the loading of the shared library.

On Windows, Matlab is already loading libstdc++-6.dll, but a different version from the one provided with the FMU.

With a debugger, I was able to get this information

LdrpSnapThunk - ERROR: Procedure "_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4findEPKcyy" could not be located in DLL "libstdc++-6.dll"
Exception thrown at 0x0000000077358078 (ntdll.dll) in MATLAB.exe: 0xC0000139: Entry Point Not Found.

One possible solution would be to link statically libstdc++ to avoid this DLL collision.

Unfortunately I spent hours going through the documentation to find a way to do such, but every attempt ended up with exactly the same result as I initially get.

This is currently blocking us to go any further in our upgrade of OpenModelica.

I can provide more informations and clarifications if needed.

Thanks.

[adrpo]

I will see if we can do this easily playing with the flags for the gcc when building the dll in template file:
​https://github.com/OpenModelica/OMCompiler/blob/master/Compiler/Template/CodegenFMU.tpl
I'm not sure if the main FMU generated C/C++ code needs libstdc++ or the supporting DLLs.
If is the supporting DLLs then it would be a bit more complicated as I would need to build static libraries for all these.

[adrpo]

As a workaround, you could try to see if using the C++ runtime would get rid of this issue by calling omc with --simCodeTarget=Cpp. As far as I remember the Cpp runtime builds just one dll without any other dependencies: omc --simCodeTarget=Cpp OMScript.mos

[sjoelund.se]

You could use the Linux version of OpenModelica to create Windows FMUs. It statically links everything (and nothing depends on C++ in there anyway).

[simon.zeni@…]

Hi,

The temporary workaround fails for a different reason on my side. The C++ DLL cannot be initialized. And I am unable to have any debug symbols from the compilation of the DLL.
Here are the flags I gave to omc

--simCodeTarget=Cpp --cppFlags=-g,-gcoff,-ggdb -d=gendebugsymbols

The DLL produced is a mere 20kb heavier, but no way to step into it with Visual Studio

[simon.zeni@…]

Replying to adrpo:

As a workaround, you could try to see if using the C++ runtime would get rid of this issue by calling omc with --simCodeTarget=Cpp. As far as I remember the Cpp runtime builds just one dll without any other dependencies: omc --simCodeTarget=Cpp OMScript.mos

I am currently digging this path since there isnt much activity. Do you have a link to the procedure or at least documentation? I cant find anything.
Thanks.

[adrpo]

Duplicate of #5035 which is now fixed.