[Bug 599227] New: mingw <pthread.h> is broken

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: mingw <pthread.h> is broken

https://bugzilla.redhat.com/show_bug.cgi?id=599227

Summary: mingw <pthread.h> is broken
           Product: Fedora
           Version: 13
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: medium
          Priority: low
         Component: mingw32-pthreads
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
         QAContact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]
    Classification: Fedora
    Target Release: ---

Description of problem:
The cross-compilation header
/usr/i686-pc-mingw32/sys-root/mingw/include/pthread.h, installed as part of the
mingw32-pthreads package, has several coding bugs.

Version-Release number of selected component (if applicable):
mingw32-pthreads-2.8.0-10.fc13.noarch

How reproducible:
Always

Steps to Reproduce:
1. Try cross-compiling any code that uses localtime_r with a second argument
with side effects, or try calling (localtime_r)(arg1,arg2).
2. Try cross-compiling any project that uses gnulib's <time.h> replacement
header (libvirt is an example project; it includes a ./autobuild.sh script that
will automatically try a mingw cross-compilation, if you have installed a mingw
portablexdr library, although that library is not yet part of fedora).

Actual results:
The definition of localtime_r is broken, because it evaluates the second
argument twice.  And, since POSIX allows one to #undef localtime_r, but there
is no localtime_r function in the library, you get a link failure if you bypass
the function-like macro.  Finally, the pthreads-win32 library made the mistake
of installing <config.h>, which is asking for namespace collision with most
other autotooled packages.

Expected results:
<pthread.h> should not define any *_r functions, nor should it interfere with a
proper <time.h>.  Also, the library should not install <config.h>, but should
instead modify its installed headers to be self-contained.

Additional info:
See this thread on bug-gnulib for more details:
http://lists.gnu.org/archive/html/bug-gnulib/2010-06/msg00007.html