Build (1.7) fails on MinGW due to undefined pthread_t

[GoogleCodeExporter]

config.h specifically disables pthreads on MinGW by undefining HAVE_PTHREAD
But the failing location in the header, not ifdefed by HAVE_PTHREAD, still uses 
pthread_t, see attached log.

Original issue reported on code.google.com by yuriv...@yahoo.com on 10 Jun 2011 at 11:54

Attachments:

• build-mingw.log

[GoogleCodeExporter]

When I tried to build it without '#undef HAVE_PTHREADS' I get more errors.

Original comment by yuriv...@yahoo.com on 11 Jun 2011 at 12:06

Attachments:

• build-mingw-with-pthread.log

[GoogleCodeExporter]

Yeah, this looks like a commit that broke mingw -- we don't test on every 
platform for every commit (though we do before every release).  We'll 
definitely fix it up before the next release.  If you'd like to submit a patch, 
that will get it fixed up earlier! :-)

It looks like pthread_t is only needed here to guard against some old libc 
problem that undoubtedly doesn't affect mingw.  So it should be enough to just 
change thread_cache.h and .cc to only do the tid_ stuff if HAVE_PTHREADS is 
#defined.  That's ugly though; it may be better to just define a pthread_t 
type, and gettid(), in the mingw config file.  (That should be easy to do, 
though I don't know windows so I don't know what the windows equivalent of 
gettid() is)

Original comment by csilv...@gmail.com on 11 Jun 2011 at 9:57

• Changed state: Accepted
• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Ah, I see this comment in mingw.h:

// Some mingw distributions have a pthreads wrapper, but it doesn't
// work as well as native windows spinlocks (at least for us).  So
// pretend the pthreads wrapper doesn't exist, even when it does.

The "some" is the clue, to me.  I bet my mingw distro does have such a wrapper, 
which is why the code compiles for me, but it doesn't for you, so you have 
problems.

I still think the best fix is to modify mingw.h, but it may be tricky since 
you'll need to figure out if a given mingw installation has pthread_t already 
defined or not.  Or something.

Original comment by csilv...@gmail.com on 11 Jun 2011 at 9:59

[GoogleCodeExporter]

Actually, I do have pthreads installed by MinGW installer. Not sure if this 
always happens now or it's optional.
I think, in addition, that HAVE_PTHREADS should be made in sync with the fact 
if it's actually installed or not. So that perftools do use threads when they 
can.

Original comment by yuriv...@yahoo.com on 11 Jun 2011 at 10:42

[GoogleCodeExporter]

When a system has both pthreads and microsoft thread library, we have to pick 
which one to use.  There's no intrinsic reason to prefer one to the other.  We 
choose microsoft threading because it seems to work better with mingw (not 
surprisingly since mingw has to emulate pthreads on top of windows).

I'm confused about what exactly the bug is, at this point.  pthread_t et al. 
are defined in src/windows/port.h if HAVE_PTHREAD is false, which it should be 
for mingw.  So you shouldn't be seeing these errors.  So what is actually going 
on in your setup, I wonder?  Are you not #including src/windows/port.h 
correctly somehow?  Or is HAVE_PTHREAD not set correctly at that point?  You 
may need to try to compile that file with -E and see what it says.

Original comment by csilv...@gmail.com on 8 Jul 2011 at 5:46

[GoogleCodeExporter]

Haven't heard anything in a while, so closing.  Feel free to reopen if (when) 
you have more info!

Original comment by csilv...@gmail.com on 18 Oct 2011 at 6:31

• Changed state: CannotReproduce