[Bug 599567] mingw32-gcc should not drag in pthreads.h because it's buggy

[bugzilla at redhat.com]

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


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

Paolo Bonzini <pbonzini at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|mingw32-gcc should not drag |mingw32-gcc should not drag
                   |in mingw32-pthreads         |in pthreads.h because it's
                   |                            |buggy

--- Comment #5 from Paolo Bonzini <pbonzini at redhat.com> 2010-10-11 06:13:18 EDT ---
> I'm not sure about splitting the packages in a runtime and a devel part.

The problem here is having mingw32-libgomp (bug 641423) would only be one step
towards fixing the problem.  The hypothetical mingw32-libgomp package would
still be required by mingw32-gcc (like libgomp is required by gcc for native
compilation), so you would still have an indirect dependency

   mingw32-gcc -> mingw32-libgomp -> mingw32-pthreads

However, the real bug here is mingw32-gcc dragging in pthreads.h.  And
pthreads.h is _not_ required to build OpenMP programs; this is why separating
the runtime and devel parts would fix the bug:

   mingw32-gcc -> mingw32-libgomp -> mingw32-pthreads (pthreadgc*2.dll)
                              |
                              `----> mingw32-pthreads-devel (BuildRequires)

That said, rereading Eric's bug report:

> It would be much nicer if the mingw32-pthreads package remained optional, 
> since it can interfere with cross-compilation efforts to mingw.

Since pthreads.h common under POSIX systems, pthreads.h can be a possible
source of problems _anyway_ when cross-compiling.  With a separate
mingw32-pthreads-devel package, the pthreads.h bug that prompted this report
would have showed up only for those people who installed
mingw32-pthreads-devel.  It would have showed up anyway, but likely only later;
and I suspect it would have been harder to track it down.

So maybe it's better to have the header uniformly installed and close this bug
as WONTFIX?



(BTW, I also agree that the behavior of lt_cv_deplibs_check_method=pass_all is
too tricky and it is probably a bad idea to have it in the RPM macros.  Libtool
behavior for Windows is sometimes confusing but at least it is safe).

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.