Opened 7 years ago
Closed 6 years ago
#4675 closed defect (fixed)
Statically link libstdc++ on Windows
Reported by: | simon.zeni@… | Owned by: | adrpo |
---|---|---|---|
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 Changed 7 years ago by adrpo
comment:2 Changed 7 years ago by adrpo
- Owner set to adrpo
- Status changed from new to accepted
comment:3 follow-up: ↓ 7 Changed 7 years ago by 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
comment:4 Changed 7 years ago by adrpo
- Component changed from *unknown* to FMI
comment:5 Changed 7 years ago by 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).
comment:6 Changed 7 years ago by 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
comment:7 in reply to: ↑ 3 Changed 7 years ago by 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.
comment:8 Changed 6 years ago by adrpo
- Resolution set to fixed
- Status changed from accepted to closed
Duplicate of #5035 which is now fixed.
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.