Lots and Lots of Unresolved External Symbols

[e-sushi]

I've been trying to integrate your code with MS Visual Studio 2019 for quite awhile now and I've come up with many errors. Currently the one I can not figure out is all these unresolved external symbols that I'm getting. I'm new to integrating libraries with Visual Studio, or anything for that matter. I'll walk you through what I've done.

I used CMake to build the binaries for a static library then in the .sln file it produced I built the solution.

After building it I placed the sockpp-static.lib and sockpp-obj.lib in a dependencies folder in the repo of the project I was testing it with. I pointed the linker at both of these files and then added the include and library directories.

It threw some weird runtime errors that I had to fix and some weird iterator debug errors that I fixed and now I'm at this point where it throws all these unresolved external symbol errors based off the sockpp-static.lib file.

It looks like this: https://i.imgur.com/NImylP6.png

It does this after I use anything to do with sockpp. For example:

        in_port_t port = 5050;

	socket_initializer sockInit;

	return 0;

will throw a bunch of errors. However if it's only in_port_t port; then it won't throw the errors.

I've tried messing with the runtime library it uses and some preprocessor settings as well. I even tried adding each of the .obj files that are generated by CMake to the Additional Directories but all that does is make it so the file that is causing the issue is no longer "sockpp-static.lib(socket.obj)" but it's "socket.obj" that's causing the problem.

Forgive me, I'm new to this. I have no clue what could be causing all these errors.

[fpagliughi]

Apologies, I'm not much of a Windows user. But this does kinda sound like what happens with MSVS if you build a library for a 32-bit target and then try to link it into an application built for a 64-bit target. Or visa versa.

For some idiotic reason the default seems to be 32-bit builds even on 64-bit versions of Windows. Assuming that you do want to build for 64-bits, when you run cmake to configure the build, be sure to tell it to do so. For VS 2019, it's like this:

cmake -g "Visual Studio 16 2019" -Ax64 ..

So that's my wild guess of what might be wrong.

[GlassBeaver]

Add this in your .h file: #pragma comment( lib, "ws2_32.lib")

Also, add the debug/release .lib files to your linker\input directories and vc++ directories\library directories.

[fpagliughi]

Ah, OK. This is the WinSock library? Can I add this to the CMake file to ensure that it gets linked in?

[GlassBeaver]

yes it is winsock - no clue if you can add it to cmake, I'm not using it too often :) what I found though is that generally you'll need that pragma comment

[mporsch]

Link to Winsock in CMake e.g. like this.

[DonnerWolfBach]

Add this in your .h file: #pragma comment( lib, "ws2_32.lib")

Also, add the debug/release .lib files to your linker\input directories and vc++ directories\library directories.

I seem to have the same problem as SushiSalad: I've build the library and configured VS'project setting to use this library.

Where do I have to add this preprocessor statement (#pragma ...)?

[fpagliughi]

Just to update this with the latest info, as of Release v0.8:

• The CMake build files were updated, and the ws2_32.lib is definitely a target dependency now.
• It seems to work fine with CMake builds for external applications, but you still need to be careful that you're not mixing 32-bit and 64-bit builds between applications and libraries.
• The shared library (DLL) build of sockpp has been fixed for Windows, and is now the default CMake build.

...but...

• When you build in Visual Studio against the raw library by just adding the .lib dependency, if you use the sharedd DLL version, it all links properly, but if you link to the static library, the ws2_32.lib dependencies are still missing and you need to add that as a dependency.

I haven't tried adding the #pragma to the library itself. I'm not sure if that's the best way to go. But in the least, I will add this info to the README, but would like to figure out how to make it so that people don't stumble on this anymore.

[mporsch]

You can tell CMake whether to propagate dependencies or not. I.e. add PUBLIC/PRIVATE keywords to your CMakeLists like this target_link_libraries(${SOCKPP_SHARED_LIBRARY} PRIVATE ${LIBS_SYSTEM}) target_link_libraries(${SOCKPP_STATIC_LIBRARY} PUBLIC ${LIBS_SYSTEM})

[fpagliughi]

Arrrgh.... I left out the "PUBLIC"?!?

https://github.com/fpagliughi/sockpp/blob/a3aad3b05012778b25966e0a2dccb01aff1e2aeb/CMakeLists.txt#L139

Thanks, @mporsch . I'll fix that.

[fpagliughi]

I hope this is all fixed in Release v0.8.1. If not, please reopen this issue.