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@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@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).