Re: [Boost-users] cross-compilation x86_64-w64-ming32: undefined reference to `InterlockedIncrement'
I have exactly the same issue with MinGW-builds gcc-4.8.1-x86_64-posix-seh building boost 1.54.0. It also crashes cxx1plus.exe as I build it (which is probably another problem). Did you manage to construct a workaround?
Well I stopped working on that. I was expecting that somebody could help with the content of <boost/detail/interlocked.hpp> but got no answer. I imagine that extern "C" long InterlockedIncrement( long volatile * ); should be extern "C" __attribute__((dllimport)) long __attribute__((__stdcall__)) InterlockedIncrement( long volatile * ); as it is in 32 bits. I have now looked a bit further: among the preprocessor variable checked in <boost/detail/interlocked.hpp>, here are the differences when compiling with i686-w64-mingw32-g++ or x86_64-w64-mingw32-g++: 1. in both cases, the following variables are undefined: WIN32 __CYGWIN__ MINGW64 _M_IA64 BOOST_MSVC BOOST_INTEL_WIN _WIN32_WCE _MSC_VER 2. in both cases, the following variables are defined with value 1: _WIN32 __WIN32 3. variable _M_AMD64 is undefined with i686-w64-mingw32-g++ and defined with value 100 with x86_64-w64-mingw32-g++. Does this help? In particular, is it normal that _WIN32 and __WIN32 are defined when targetting win64? Is it normal that MINGW64 is always undefined although I use a W64 compiler? Frédéric
Le 07/09/13 07:35, Frédéric Bron a écrit :
I have exactly the same issue with MinGW-builds gcc-4.8.1-x86_64-posix-seh building boost 1.54.0. It also crashes cxx1plus.exe as I build it (which is probably another problem). Did you manage to construct a workaround? Well I stopped working on that. I was expecting that somebody could help with the content of <boost/detail/interlocked.hpp> but got no answer.
I imagine that extern "C" long InterlockedIncrement( long volatile * ); should be extern "C" __attribute__((dllimport)) long __attribute__((__stdcall__)) InterlockedIncrement( long volatile * ); as it is in 32 bits.
I have now looked a bit further: among the preprocessor variable checked in <boost/detail/interlocked.hpp>, here are the differences when compiling with i686-w64-mingw32-g++ or x86_64-w64-mingw32-g++:
1. in both cases, the following variables are undefined: WIN32 __CYGWIN__ MINGW64 _M_IA64 BOOST_MSVC BOOST_INTEL_WIN _WIN32_WCE _MSC_VER
2. in both cases, the following variables are defined with value 1: _WIN32 __WIN32
3. variable _M_AMD64 is undefined with i686-w64-mingw32-g++ and defined with value 100 with x86_64-w64-mingw32-g++.
Does this help? In particular, is it normal that _WIN32 and __WIN32 are defined when targetting win64? Is it normal that MINGW64 is always undefined although I use a W64 compiler?
Hi, I suspect you mean __MINGW64__. #if defined(__MINGW64__) #define BOOST_INTERLOCKED_IMPORT #else #define BOOST_INTERLOCKED_IMPORT __declspec(dllimport) #endif If not. Could you check if __MINGW64__ is defined? Best, Vicente
1. in both cases, the following variables are undefined: WIN32 __CYGWIN__ MINGW64 _M_IA64 BOOST_MSVC BOOST_INTEL_WIN _WIN32_WCE _MSC_VER
2. in both cases, the following variables are defined with value 1: _WIN32 __WIN32
3. variable _M_AMD64 is undefined with i686-w64-mingw32-g++ and defined with value 100 with x86_64-w64-mingw32-g++.
Does this help? In particular, is it normal that _WIN32 and __WIN32 are defined when targetting win64? Is it normal that MINGW64 is always undefined although I use a W64 compiler?
I suspect you mean __MINGW64__.
If not. Could you check if __MINGW64__ is defined?
sorry, you're right __MINGW64__ is used in the code and it is undefined with i686-w64-mingw32-g++ and defined and equal to 1 with x86_64-w64-mingw32-g++. Cheers, Frédéric
Le 07/09/13 12:33, Frédéric Bron a écrit :
1. in both cases, the following variables are undefined: WIN32 __CYGWIN__ MINGW64 _M_IA64 BOOST_MSVC BOOST_INTEL_WIN _WIN32_WCE _MSC_VER
2. in both cases, the following variables are defined with value 1: _WIN32 __WIN32
3. variable _M_AMD64 is undefined with i686-w64-mingw32-g++ and defined with value 100 with x86_64-w64-mingw32-g++.
Does this help? In particular, is it normal that _WIN32 and __WIN32 are defined when targetting win64? Is it normal that MINGW64 is always undefined although I use a W64 compiler?
I suspect you mean __MINGW64__.
If not. Could you check if __MINGW64__ is defined? sorry, you're right __MINGW64__ is used in the code and it is undefined with i686-w64-mingw32-g++ and defined and equal to 1 with x86_64-w64-mingw32-g++.
I have no idea why this was added (https://svn.boost.org/trac/boost/changeset/70383). Could you try commenting so that #define BOOST_INTERLOCKED_IMPORT __declspec(dllimport) ? Could some one clarify why this was needed? Best, Vicente
Could you try commenting so that #define BOOST_INTERLOCKED_IMPORT __declspec(dllimport) ?
So I forced that: #define BOOST_INTERLOCKED_IMPORT __declspec(dllimport) I rebuilt boost with the following commands: CC=x86_64-w64-mingw32-gcc\ CXX=x86_64-w64-mingw32-g++\ ./bootstrap.sh --without-icu --prefix=build --with-toolset=gcc echo "using gcc : : x86_64-w64-mingw32-g++ : <compileflags>-DBOOST_THREAD_USE_LIB ;" > user-config.jam mkdir build ./b2 -d2 -j8 --layout=system --user-config=user-config.jam --without-mpi --without-python\ link=static\ threading=multi\ runtime-link=shared\ address-model=64\ instruction-set=nocona\ target-os=windows\ threadapi=win32\ variant=release\ install > build/build.log 2>&1 but still got the following error: x86_64-w64-mingw32-g++ -o mgw64-release/obj/Tests/xuxu2.o -c -O3 -DNDEBUG -DWINDOWS -std=c++11 -Wall -Wextra -pipe -ffloat-store -I/home/fred/boost-1.54.0/include -DBOOST_DISABLE_ASSERTS -DBOOST_FILESYSTEM_VERSION=3 -DBOOST_FILESYSTEM_NO_DEPRECATED -DBOOST_THREAD_USE_LIB -I. Tests/xuxu2.cc x86_64-w64-mingw32-g++ -o mgw64-release/bin/xuxu2.exe mgw64-release/obj/Tests/xuxu2.o -Wl,--enable-auto-import -static -L/home/fred/boost-1.54.0/lib -lboost_thread-mt -lboost_system-mt -mthreads mgw64-release/obj/Tests/xuxu2.o:xuxu2.cc:(.text$_ZN5boost6threadD1Ev[_ZN5boost6threadD1Ev]+0x1a): undefined reference to `InterlockedDecrement' mgw64-release/obj/Tests/xuxu2.o:xuxu2.cc:(.text.startup+0xf6): undefined reference to `InterlockedIncrement' /usr/lib64/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: mgw64-release/obj/Tests/xuxu2.o: bad reloc address 0xf6 in section `.text.startup' collect2: error: ld returned 1 exit status I have also made a minimal example so that anybody can test: #include <iostream> #include <boost/thread.hpp> struct Runner { void operator()() const { std::cout<<"Runner::operator()\n"; } }; int main(int, char*[]) { Runner r; boost::thread t1(r); t1.join(); return 0; } Cheers, Frédéric
On 8 September 2013 06:21, Frédéric Bron <frederic.bron@m4x.org> wrote:
mgw64-release/obj/Tests/xuxu2.o:xuxu2.cc:(.text$_ZN5boost6threadD1Ev[_ZN5boost6threadD1Ev]+0x1a): undefined reference to `InterlockedDecrement' mgw64-release/obj/Tests/xuxu2.o:xuxu2.cc:(.text.startup+0xf6): undefined reference to `InterlockedIncrement'
/usr/lib64/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: mgw64-release/obj/Tests/xuxu2.o: bad reloc address 0xf6 in section `.text.startup' collect2: error: ld returned 1 exit status
I have also made a minimal example so that anybody can test: #include <iostream> #include <boost/thread.hpp> struct Runner { void operator()() const { std::cout<<"Runner::operator()\n"; } }; int main(int, char*[]) { Runner r; boost::thread t1(r); t1.join(); return 0; }
Cheers,
Frédéric
Hi, It looks like boost needs to handle the mingw case differently. See this thread and the patch within it. http://sourceforge.net/mailarchive/message.php?msg_id=31189847 I haven't had time to test whether it resolves the issue, but try it out and let us know. Cheers, Vitaly
It looks like boost needs to handle the mingw case differently. See this thread and the patch within it. http://sourceforge.net/mailarchive/message.php?msg_id=31189847
I haven't had time to test whether it resolves the issue, but try it out and let us know.
So I tried to apply this patch to 1.54.0: http://sourceforge.net/mailarchive/attachment.php?list_name=mingw-w64-public&message_id=1374418938.8920.43.camel%40erik-laptop.terneuzen.vanpienbroek.nl&counter=1 But this did not solve my issue with "undefined reference to `InterlockedDecrement'". Frédéric
participants (4)
-
Frédéric Bron -
Vicente J. Botet Escriba -
Vitaly Budovski