Opened 7 years ago

Closed 6 years ago

#4675 closed defect (fixed)

Statically link libstdc++ on Windows

Reported by: simon.zeni@… Owned by: Adrian Pop
Priority: blocker Milestone: 1.13.0
Component: FMI Version: v1.12.0
Keywords: static linking libstdc++ Cc:

Description

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.

Change History (8)

comment:1 by Adrian Pop, 7 years ago

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.

comment:2 by Adrian Pop, 7 years ago

Owner: set to Adrian Pop
Status: newaccepted

comment:3 by Adrian Pop, 7 years ago

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

comment:4 by Adrian Pop, 7 years ago

Component: *unknown*FMI

comment:5 by Martin Sjölund, 7 years ago

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

comment:6 by simon.zeni@…, 7 years ago

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

in reply to:  3 comment:7 by simon.zeni@…, 7 years ago

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.

comment:8 by Adrian Pop, 6 years ago

Resolution: fixed
Status: acceptedclosed

Duplicate of #5035 which is now fixed.

Note: See TracTickets for help on using tickets.