On Mon, Sep 23, 2013 at 2:46 PM, Frédéric Bron <frederic.bron@m4x.org>wrote:

...

I probably missed the original problem, but the patch doesn't look correct to me. The section guarded with "defined( BOOST_MSVC ) || defined( BOOST_INTEL_WIN )" is obviously targeted for compilers supporting interlocked intrinsics, which gcc isn't. MinGW should probably be handled by the last section of the #if/elif/endif sequence. Anyway, what problem are you trying to fix?

Here is what I get when build an application with boost and mingw-w64 targeting x86_64:

/usr/x86_64-w64-mingw32/sys- root/mingw/lib/../lib/libboost_thread-mt.a(thread.o):(.text+0x286): undefined reference to `InterlockedIncrement'

/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libboost_thread-mt.a(thread.o):(.text+0x3e7): undefined reference to `InterlockedDecrement'

/usr/lib64/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld:

/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libboost_thread-mt.a(thread.o): bad reloc address 0x8 in section `.data'

I have been able to solve this by defining BOOST_USE_WINDOWS_H but this creates issues with Unicode when I also use wxWidgets. The patch proposed solves the issue. I recognise that I say that gcc should be considered as MSVC with regards to these Interlocked things which I do not understand. It may seem strange but it works. What's wrong with it? Basically, I just #include <intrin.h>; what's wrong with that?

It makes the code less clear. Also, intrin.h is an MSVC-specific header and I'm not sure it's portable across different versions of MinGW. Does it help if you just replace: #if defined(__MINGW64__) #define BOOST_INTERLOCKED_IMPORT #else #define BOOST_INTERLOCKED_IMPORT __declspec(dllimport) #endif with #define BOOST_INTERLOCKED_IMPORT BOOST_SYMBOL_IMPORT and no other changes? If that fixes the problem, this would be a more appropriate solution for 1.55. In the long term it might be worthwhile to use gcc atomic intrinsics to implement BOOST_INTERLOCKED* macros.

On Mon, Sep 23, 2013 at 4:02 PM, Peter Dimov <lists@pdimov.com> wrote:

Andrey Semashev wrote:

...

Also, intrin.h is an MSVC-specific header and I'm not sure it's portable across different versions of MinGW.

<intrin.h> in this context probably includes the MingW64 header of that name.

I understand.

In the long term it might be worthwhile to use gcc atomic intrinsics to

...

implement BOOST_INTERLOCKED* macros.

BOOST_INTERLOCKED_* are not supposed to be implemented. If Boost.Thread uses them instead of the appropriate gcc atomics, this is a problem in Boost.Thread, not in interlocked.hpp.

The macros are supposed to provide low level atomic ops on Windows, aren't they? Wouldn't it be better to use gcc atomic intrinsics instead of WinAPI calls in case of MinGW? I'm not disputing now whether Boost.Thread should be based on Boost.Atomic, or whatever other abstraction layer.

On Mon, Sep 23, 2013 at 5:48 PM, Peter Dimov <lists@pdimov.com> wrote:

Andrey Semashev wrote:

...

The macros are supposed to provide low level atomic ops on Windows, aren't they? Wouldn't it be better to use gcc atomic intrinsics instead of WinAPI calls in case of MinGW?

No, the macros were supposed to be a portable way of accessing the Interlocked* family of WinAPI calls without having to #include <windows.h>. That's probably why shared_ptr doesn't have a problem on MingW64 - it uses a g++ specific implementation there. (Interlocked* later mutated into compiler intrinsics.)

Yes, MinGW-w64 defines _Interlocked* functions in terms of gcc intrinsics internally, in intrin.h. This header is only available in MinGW-w64 and not MinGW (the original project). Considering all that I prepared a patch for interlocked.hpp (attached, the patch is against trunk).

Yes, MinGW-w64 defines _Interlocked* functions in terms of gcc intrinsics internally, in intrin.h. This header is only available in MinGW-w64 and not MinGW (the original project). Considering all that I prepared a patch for interlocked.hpp (attached, the patch is against trunk).

Just tested your patch with both i686-w64-mingw32-g++ and x86_64-w64-mingw32-g++. Works nicely, you can apply the patch. Kind regards, Frédéric

Does it help if you just replace:

#if defined(__MINGW64__) #define BOOST_INTERLOCKED_IMPORT #else #define BOOST_INTERLOCKED_IMPORT __declspec(dllimport) #endif

with

#define BOOST_INTERLOCKED_IMPORT BOOST_SYMBOL_IMPORT

and no other changes? If that fixes the problem, this would be a more appropriate solution for 1.55. In the long term it might be worthwhile to use gcc atomic intrinsics to implement BOOST_INTERLOCKED* macros.

target i686 is OK but target x86_64 gives this error: xuxu-x86_64-w64-mingw32-g++-4.8.1.o:xuxu.cc:(.text+0x1b7): undefined reference to `__imp_InterlockedIncrement' xuxu-x86_64-w64-mingw32-g++-4.8.1.o:xuxu.cc:(.text$_ZN5boost6detail21intrusive_ptr_releaseEPNS0_16thread_data_baseE[_ZN5boost6detail21intrusive_ptr_releaseEPNS0_16thread_data_baseE]+0xe): undefined reference to `__imp_InterlockedDecrement' /cm/shared/apps/soft/bal/usr/mingw64-4.8.1/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: xuxu-x86_64-w64-mingw32-g++-4.8.1.o: bad reloc address 0xe in section `.text$_ZN5boost6detail21intrusive_ptr_releaseEPNS0_16thread_data_baseE[_ZN5boost6detail21intrusive_ptr_releaseEPNS0_16thread_data_baseE]' collect2: error: ld returned 1 exit status Frédéric

Frédéric Bron wrote:

...

I don't understand why your patch removes the definition of BOOST_INTERLOCKED_IMPORT. Doesn't this break every use of this macro?

in fact, I am not using this section with mingw-w64 but the section that was used for MSVC before.

I know. Other compilers are using this section though, and they will break if the definition is removed. Which is why I asked why you decided to remove it.

Frédéric Bron wrote:

Oh, of course, here is the correct path.

This patch looks OK to me.