Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unresolved symbol when trying to build shared lib #213

Closed
PascalRunde opened this issue Jan 20, 2023 · 8 comments
Closed

Unresolved symbol when trying to build shared lib #213

PascalRunde opened this issue Jan 20, 2023 · 8 comments

Comments

@PascalRunde
Copy link

PascalRunde commented Jan 20, 2023

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.

@asmaloney
Copy link
Owner

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

@asmaloney
Copy link
Owner

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.

@asmaloney
Copy link
Owner

(Note: My last change is not related to this issue, though it is touching the same code.)

@asmaloney
Copy link
Owner

asmaloney commented Jan 21, 2023

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:

@PascalRunde
Copy link
Author

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.

@PascalRunde
Copy link
Author

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.

@asmaloney
Copy link
Owner

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!

asmaloney added a commit that referenced this issue Jan 24, 2023
Put the test executable next to the DLL.

Also changes builds to use validation level 2 by default.

Addresses part of #213
@asmaloney
Copy link
Owner

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants