3
votes

I'm on a fedora 19 x86_64 computer, with mingw64 and all the relevant packages installed. I was working on a personal c++ project, and i decided to make it thread-safe, and so I decided to give Boost.thread synchronization objects a try. As soon as I did, I started to get linker errors related to InterlockedCompareExchange. The following test program illustrates my point:

#include <boost/thread/locks.hpp>
#include <boost/thread/shared_mutex.hpp>

int main()
{
    boost::shared_mutex mtx;
    boost::unique_lock<decltype(mtx)> lck{mtx};
}

Here's the command line (I put -lboost_thread-mt because there's no non-multithreaded version, which makes sense):

$ x86_64-w64-mingw32-g++ -std=c++11 test.cpp -o test -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lboost_thread-mt -lboost_system

/tmp/cc4Wh6PO.o:test.cpp:(.text$_ZN5boost12shared_mutex28interlocked_compare_exchangeINS0_10state_dataEEET_PS3_S3_S3_[_ZN5boost12shared_mutex28interlocked_compare_exchangeINS0_10state_dataEEET_PS3_S3_S3_]+0x2f): undefined reference to `InterlockedCompareExchange' collect2: error: ld returned 1 exit status

But with mingw32 it compiles like a charm:

$ i686-w64-mingw32-g++ -std=c++11 test.cpp -o test -I/usr/i686-w64-mingw32/sys-root/mingw/include -L/usr/i686-w64-mingw32/sys-root/mingw/lib -lboost_thread-mt -lboost_system

My question is: am I doing something wrong or is it a bug in mingw64? Does it compile with the windows version of mingw?

Edit: actually it did, so it must be a bug in the fedora mingw64 package

3
This question appears to be off-topic because it is a bug report.rubenvb
This was fixed recently. Try updating your toolchain from the Fedora repos. If you experience this again, please submit a bug report to the Fedora tracker instead of using Stackoverflow as a fix-all.rubenvb
I've given up on using boost::thread via MINGW64/GCC 4.7.1 (must build -m32 due to Irrlicht not being able to build 64-bit) due to this problem CreateThread and windows-only (sucks) it is I guess... :( some defines indicating 64-bit MINGW still are true when -m32 and trips up the workaround macros to fix the _Interlocked and friends from failing. I even tried creating a stub in one of my .cpp files for the failing _Itnerlocked* functions and still couldn't get it past the linker.Brian Jack
there are cases where this has not been fixed (eg: -m32 when using minGW/GCC 4.7.1) so someone in the know to create a workaround would be a useful answer here.Brian Jack
The InterlockedCompareExchange undefined errors are fixed in boost version 1.55.0.nmgeek

3 Answers

4
votes

Based on this page http://sourceforge.net/apps/trac/mingw-w64/wiki/Building%20Boost, you can add define=BOOST_USE_WINDOWS_H to avoid that linking error. It works for me.

2
votes

In fact I still keep getting the same results, so I will definitely report it. Thanks

0
votes

I encountered similar issue of undefined reference to Interlocked* functions. As far as I know, mingw64 rev2 from MinGWBuilds project (on sf) is working, while rev3 is not working. So I belive it is something changed in MinGW64.