ValveSoftware
pthread mismatch on msys2
I'm trying to use GNS with my own sort-of game engine on top of SDL2, linking statically for less clutter using msys2 on windows. My OS is windows 10 and I'm using a laptop in case it matters. My code is mostly written in C as well, but with the portion that interacts with GNS being C++. I tried following the instructions in BUILDING.md, but ran into couple issues. Firstly, neither ninja nor msys make could detect the platform, so I kept getting an #error Unknown Platform message (from CSteamNetworkingUtils::GetPlatformString ). I currently have that dealt with by add_definitions(-D_WINDOWS) into the base CMakeLists.txt file. After that and some updating of stuff that's probably more msys2's fault, it built fine.
Here's the main issue I'm having trouble with: when I try to build the engine's executable, I get this error:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../lib\libGameNetworkingSockets_s.a(opensslwrapper.cpp.obj):C:/msys64/mingw64/include/c++/10.2.0/x86_64-w64-mingw32/bits/gthr-default.h:749: undefined reference to `__imp_pthread_mutex_lock'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../lib\libGameNetworkingSockets_s.a(opensslwrapper.cpp.obj):C:/msys64/mingw64/include/c++/10.2.0/x86_64-w64-mingw32/bits/gthr-default.h:779: undefined reference to `__imp_pthread_mutex_unlock'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../lib\libGameNetworkingSockets_s.a(opensslwrapper.cpp.obj):C:/msys64/mingw64/include/c++/10.2.0/x86_64-w64-mingw32/bits/gthr-default.h:687: undefined reference to `__imp_pthread_self'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../lib\libGameNetworkingSockets_s.a(opensslwrapper.cpp.obj):C:/msys64/mingw64/include/c++/10.2.0/x86_64-w64-mingw32/bits/gthr-default.h:749: undefined reference to `__imp_pthread_mutex_lock'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../lib\libGameNetworkingSockets_s.a(opensslwrapper.cpp.obj):C:/msys64/mingw64/include/c++/10.2.0/x86_64-w64-mingw32/bits/gthr-default.h:779: undefined reference to `__imp_pthread_mutex_unlock'
collect2.exe: error: ld returned 1 exit status
I've tried googling and messing with different linker options and versions of pthread (winpthread, pthread-win32, etc.). I've also tried messing with the source to see if I can find and comment out any dll import macros. The same errors occur regardless.
The command for linking uses these flags:
-l mingw32 -l SDL2main -l SDL2_mixer -l SDL2_ttf -l SDL2 -l freetype -l vorbisfile -l vorbis -l ogg -l png -l z -l GameNetworkingSockets_s -lssl -lcrypto -lssl -lprotobuf -lcrypt32 -lWs2_32 -mwindows -l m -l dinput8 -l dxguid -l dxerr8 -l setupapi -l user32 -l gdi32 -l winmm -l imm32 -l ole32 -l oleaut32 -l shell32 -l version -l uuid -static-libstdc++ -static-libgcc -pthread -static
Is there some other flag or dependency that I'm missing? Alternatively, is that CMake command screwing something up?
I really have no idea what the problem is here. @tycho might have some time to setup an msys2 environment to reproduce and investigate, but no promises. msys2 support is not really a top priority for us, I apologize.
I applied a fix in a6fa72e1350be7beafec17dd915f384b65f6531c to add the missing _WINDOWS macro definition for MinGW, and things built fine for me without any other changes added.
Can you retry against the latest revision, and provide full repro steps if it's still a problem?
Well, I tried first to just build the library again following the build instructions followed by linking my engine again. Now protobuf is complaining. I don't remember if that happened last time. Still, that can be made to stop if I tell it to link to protobuf.dll instead. The error I posted before still occurs, and if I try to link to winpthread.dll, I get an error because of multiple definitions due to at least one of the other libraries using the static version. This is the same behavior as before.
So, as requested I tried find a way to easily reproduce the error without having to post the full engine. The first thing that came to mind was to try to statically build example_chat.cpp, then progressively add code using the other libraries until one would break it. The problem is that it didn't work from the get go.
With example.cpp in its own directory, and all the library files in places they could be found, I compiled using this command:
g++ example_chat.cpp -o example_chat.exe -l GameNetworkingSockets_s
The result, after taking out the director info to make it more readable, was this:
ld.exe: example_chat.cpp:(.text+0x32e): undefined reference to `__imp_GameNetworkingSockets_Init'
ld.exe: example_chat.cpp:(.text+0x3c2): undefined reference to `__imp_GameNetworkingSockets_Kill'
ld.exe: example_chat.cpp:(.text$_Z22SteamNetworkingSocketsv[_Z22SteamNetworkingSocketsv]+0xb): undefined reference to `__imp_SteamNetworkingSockets_LibV9'
ld.exe: example_chat.cpp:(.text$_Z20SteamNetworkingUtilsv[_Z20SteamNetworkingUtilsv]+0xb): undefined reference to `__imp_SteamNetworkingUtils_LibV3'
ld.exe: example_chat.cpp:(.text$_ZNK21SteamNetworkingIPAddr8ToStringEPcyb[_ZNK21SteamNetworkingIPAddr8ToStringEPcyb]+0x36): undefined reference to `__imp_SteamNetworkingIPAddr_ToString'
ld.exe: example_chat.cpp:(.text$_ZN21SteamNetworkingIPAddr11ParseStringEPKc[_ZN21SteamNetworkingIPAddr11ParseStringEPKc]+0x1e): undefined reference to `__imp_SteamNetworkingIPAddr_ParseString'
In case it wasn't clear before, let me emphasize: this is only a problem with static linking. Everything works fine if dynamic linking is used instead.
Does it work if you link with something like:
g++ example_chat.cpp -o example_chat.exe -l GameNetworkingSockets_s -lpthread.dll
or
g++ example_chat.cpp -o example_chat.exe -l GameNetworkingSockets_s -pthread
I don't yet understand why the link works fine for me but not for you.
Neither of those changed anything. I'm going to try doing a fresh install of msys2 in a different spot so I can see if my previous programming stuff might have messed something up.
Edit 4 hours later: Nope. I've tried 2 fresh installs of the latest version of msys2 (uploaded to their site on 1/08/21), one that followed the build directions as written and one that used pkgconf instead of pkg-config. Both give me the same result. It shouldn't be any other library getting in the way either. I only have the initial updates from "pacman -Syuu", the basic toolchain, cmake, ninja and the listed dependencies installed on these copies of msys2.
Edit again: Oh...I completely forgot that I'd noticed the need for STEAMNETWORKINGSOCKETS_STATIC_LINK to be defined, and put that at the beginning the code for use with my engine. When I went back to reproduce the errors, I didn't have that defined. With a bit more trial and error I have found that this command will produce the same errors as I originally ran into
g++ example_chat.cpp -o example_chat.exe -l GameNetworkingSockets_s -D STEAMNETWORKINGSOCKETS_STATIC_LINK -l protobuf.dll -l crypto -l ssl -l Ws2_32 -static
Using -pthread -lpthread or -lwinpthread doesn't matter. Whether or not crypto or ssl have .dll instead doesn't matter. Not having .dll for protobuf causes a huge number of symbols to fail to link, presumably because I didn't use that option in the cmake files for static linking to it.
My apologies if there's a spot where that static linking flag is listed and I missed it. If not and it's not something that cmake just failed to apply automatically, I think it should be listed somewhere.
Came across this issue too. I was compiling with TDM-GCC, tried downloading libpthread and got duplicate symbols.
Sorry, I'm gonna close this because I don't really want to officially support msys.