Re: [Mingw-w64-public] winpthreads and GCC's posix-threads only features (eg C++0x std::thread)

[K. F. <kfr...@gm...>]

Hi Ruben!

On Mon, Jun 13, 2011 at 2:54 PM, Ruben Van Boxem
<van...@gm...> wrote:
> 2011/6/13 Ruben Van Boxem <van...@gm...>:
>> 2011/6/13 Ruben Van Boxem <van...@gm...>:
>>> Ok, I ran into some problems with "--enable-threads=posix"...
>>> ...
>> 2. C++0x std::thread is not automagically enabled. Specifically, I
>> needed to perform the following manual steps (taken from K. Frank's
>> howto here: http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTikwrRkzOuUdKOO2ShYSG7zqt8qq3QmXPfZsYhGa%40mail.gmail.com&forum_name=mingw-w64-public):
>>  - Add "-D_POSIX_TIMEOUTS -D_GLIBCXX__PTHREADS
>> -D_GLIBCXX_HAS_GTHREADS" to the commandline, along with "-std=c++0x"
>> of course.
>>  - Uncomment the line in bits/error_constants.h (strange, Explorer
>> won't show this file, but grep found it anyways... it's not hidden
>> either)
>>  - And that ends up in an undefined reference to "std::thread::join()".
>>
>> I must be doing something wrong then :(

I had the same problem (undefined reference to "std::thread::join()")
getting std::thread to work.  Of course, in my case, I wasn't building
g++ -- I was using a pre-built g++, and tweaking the environment to
get std::thread to work.  (That's a long way of saying that even though
Ruben and I see the same symptom, we may have different causes.)

Anyway, std::thread is not pure header, but has some (compiled)
implementation somewhere.  (I assume that it's in libstdc++, but
I never tried to verify that.)  The source code for the implementation
for std::thread, thread.cc (and other files), is basically entirely
protected by:

   #if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)

In my case -- linking against a pre-built libstdc++ (or whatever
library has the std::thread implementation) -- I got the undefined
reference, presumably because when the implementation
library was built, _GLIBCXX_HAS_GTHREADS was not defined.

So in my case, I simply added the source file thread.cc (and
some others) to the compile line when I compiled my program
that used std::thread.  Because that compile command had
_GLIBCXX_HAS_GTHREADS explicitly defined, the content of
thread.cc got compiled (no longer #ifdef'ed out) and provided the
function std::thread::join() for my program at link time.

However, if you're building a new g++ from the ground up (including
the standard libraries), then I would think that having

   _GLIBCXX_HAS_GTHREADS

(and other required macros) defined at build time would cause the
implementation for std::thread::join() contained in thread.cc to
be compiled and linked into libstdc++ (or whatever the right library
is), and therefore std::thread::join() should be available when you
compile and link a test program using your newly built g++.

Anyway, this is just a suggestion -- maybe Ruben is seeing a
different problem that happens to have a similar symptom.

>
> Like for example adding "--disable-static" to the GCC configure line.
> This probably caused the linker error, although the libstdc++.dll.a
> import library should've been used, no? Qmake also wouldn't build,
> because libstdc++.a was missing, that's how I found out. Maybe the
> std::thread things aren't properly exported from the shared libstdc++
> build?

This suggestion -- that libstdc++ does contain std::thread::join(), but
that it is not being exported -- seems plausible.

My copy of thread.cc (where std::thread::join() is implemented) came,
I believe, from the non-mingw-ized gnu source.  In any event, it does not
have any of that dllexport / dllimport stuff that I've never truly understood
the need for, but that seems to be necessary in the windows world.

Let's say that you're compiling thread.cc with

   _GLIBCXX_HAS_GTHREADS

defined.  Then the std::thread::join() implementation should be in the
object file and presumably also the library.  But if the mingw-w64 source
has a "bug" in that std::thread::join() isn't getting exported, then you
would get your undefined reference.  And the "bug" would never be
noticed until someone tried to build the library with

   _GLIBCXX_HAS_GTHREADS

defined.

>
> I'm rebuilding now to see where I can get.
> ...
>> Ruben

Thanks again for your effort and for making your builds available.

Please let me know if there is any more detail I can offer that
might be helpful.

Best.


K. Frank