Unresolved symbol when trying to build shared lib
PascalRunde opened this issue · 8 comments
On windows:
I get an error
Unresolved external symbol: ""class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl e57::floatingPointToStr<double>(double,int)" (??$floatingPointToStr@N@e57@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@NH@Z)".
which seems to refer to the floatingPointToStr function template in Stringfunctions.cpp.
I am not experienced with C++ and I can not find out how to solve this.
Note: I am using the latest commit on Master and disabled "Warnings_as_Errors" because there were some issues with E57Exception.
Thanks Pascal. I don't have Windows, but I'll take a look and see what might be wrong. Windows needs some strange magic that might be missing. 🪄
It's not the strange magic I was thinking - what version of MSVC are you building with? Can you include the CMake command you're using to build?
because there were some issues with E57Exception.
Could you please add an issue with the errors you're getting? It should build with that on.
The GitHub workflows are building fine with Windows, so I need to figure out what's different about your setup.
(Note: My last change is not related to this issue, though it is touching the same code.)
It turns out that the CI wasn't building Windows with shared libs, so that was part of the issue. I spent all day yesterday looking at Windows DLLs and trying to debug this with GitHub workflows.
Things Windows DLLs don't like:
- classes inheriting from
std:exception - using any STD library classes (like
std::string) in any exported class (not fixed, but turned the warning off - no idea if this is even fixable) - template specialization in cpp files (requires some of the aforementioned strange magic 🪄 )
- internal functions that aren't exported for test program linking with a DLL
I think I have fixed these (commits incoming) and it all builds, but for the life of me I can't get the test build for Windows with shared libraries to run on the CI and it gives no information. The paths all look correct (for the xerces DLL).
So I'm going to commit what I have and you can see if it fixes things on your end.
Fixes:
Sorry for not responding yet, I have been ill at the weekend. Thank you very much for the fast response and effort. I will definitely have a look at it and try to fix the issue with the test build.
Turns out the testE57.exe needs to find the E57Format.dll as well as the xerces-c_3_2.dll and there are two ways to do this: Either specify these within the PATH environment variable or copy them to the same folder as the testE57.exe. I copied them manually and the tests worked just fine.
I have been ill at the weekend
Hope you're feeling better!
Turns out the testE57.exe needs to find the E57Format.dll
🤦 Ah. Of course - it's being built in a different directory from the test. I guess the Linux & macOS builds handle this properly. I'll need to figure out how to add that path to the Windows CI. Thanks!
I think Windows shared libs should be working now.
The Windows shared lib builds must have been spewing warnings forever, but nobody reported them. Glad to get it fixed up.
Thanks for reporting this Pascal!