[Bug 599567] New: mingw32-gcc should not drag in mingw32-pthreads

[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: mingw32-gcc should not drag in mingw32-pthreads

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

Summary: mingw32-gcc should not drag in mingw32-pthreads
           Product: Fedora
           Version: 13
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: medium
          Priority: low
         Component: mingw32-gcc
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
         QAContact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail],
                    [e-mail]
    Classification: Fedora
    Target Release: ---

Description of problem:
mingw32-gcc currently drags in a dependency on mingw32-pthreads, which in turn
forces some namespace pollution due to its buggy <pthread.h> header.  It would
be much nicer if the mingw32-pthreads package remained optional, since it can
interfere with cross-compilation efforts to mingw.

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

How reproducible:
Always

Steps to Reproduce:
1. Install mingw32-gcc

Actual results:
mingw32-pthreads gets sucked in as a required dependency to the cross-compiler.

Expected results:
Mere presence of the cross-compiler shouldn't force the existence of a broken
<pthread.h>.  Either the compiler needs to be built without mingw32-pthreads,
or mingw32-pthreads needs to be split into two packages (runtime dependency of
the compiler, vs. development library that installs <pthread.h> for situations
that actually want to use this library in spite of its current upstream flaws).

Additional info:

[Bug 599567] mingw32-gcc should not drag in mingw32-pthreads

[Red Hat Bugzilla]

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

Eric Blake  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.redhat.com
                   |                            |/show_bug.cgi?id=599227

[Bug 599567] mingw32-gcc should not drag in mingw32-pthreads

[Red Hat Bugzilla]

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

--- Comment #1 from Eric Blake  2010-06-03 10:09:57 EDT ---
See also this thread in the libvirt list:

https://www.redhat.com/archives/libvir-list/2010-June/msg00075.html

[Bug 599567] mingw32-gcc should not drag in mingw32-pthreads

[Red Hat Bugzilla]

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  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |641423

[Bug 599567] mingw32-gcc should not drag in mingw32-pthreads

[Red Hat Bugzilla]

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

--- Comment #2 from Paolo Bonzini  2010-10-08 13:20:55 EDT ---
The dependency is brought in by libgomp, see bug 641423.

[Bug 599567] mingw32-gcc should not drag in mingw32-pthreads

[Red Hat Bugzilla]

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  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #3 from Paolo Bonzini  2010-10-09 05:52:59 EDT ---
... however, since libgomp should be required by gcc, fixing this bug would
require splitting mingw packages in a "deployment" part and a "devel" part. 
This way, gcc would bring in mingw32-pthreads but not mingw32-pthreads-devel.

[Bug 599567] mingw32-gcc should not drag in mingw32-pthreads

[Red Hat Bugzilla]

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

Erik van Pienbroek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |[e-mail]

--- Comment #4 from Erik van Pienbroek  2010-10-09 07:02:47 EDT ---
The mingw32-pthreads dependency seems to be introduced by this commit
http://pkgs.fedoraproject.org/gitweb/?p=mingw32-gcc.git;a=commitdiff;h=4d493...
which added libgomp support.
I agree with you that we should avoid having this dependency on the base
mingw32-gcc package.

I'm not sure about splitting the packages in a runtime and a devel part. When
libraries are being linked to a binary by libtool then both the .dll.a file and
the .dll file itself are required. If the .dll file is missing then libtool
spits out a warning and refuses to build shared libraries. There is a hack to
ignore this behavior but I don't know if it's a good idea to add it to the
default RPM macros as it can masquerade packaging errors. The hack in question
is: export lt_cv_deplibs_check_method="pass_all"

Moving all libgomp files to a separate subpackage seems like the only sane
solution to me. Perhaps anybody else in the MinGW SIG has a more proper
solution?

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

[Red Hat Bugzilla]

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

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

[Red Hat Bugzilla]

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

--- Comment #6 from Erik van Pienbroek  2010-10-11 08:13:04 EDT ---
As I see it we have two possible solutions to this bug:
1. Split the mingw32-pthreads package in a runtime and a devel part
   Cons: The BuildRequires of various other packages depending on
mingw32-pthreads have to be updated
   Cons: There are no other packages in the Fedora MinGW toolchain which have
-devel subpackages making it inconsistent with the rest of the packages
2. Link libgomp statically against pthreads eliminating the hard dependency on
the mingw32-pthreads package
   Cons: Might require approval from FESCO as packages aren't allowed to link
statically against each other

I would vote for the second option, but I don't know if the others agree with
me on that

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

[Red Hat Bugzilla]

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

--- Comment #7 from Daniel Berrange  2010-10-11 08:35:20 EDT ---
Having a separate '-devel' package seems wrong to me. All mingw32 packages are
essentially '-devel' packages, which is why our packaging guidelines never
suggest actually creating -devel packages.

The 3rd option would be to try and fix pthreads.h so that it doesn't pollute
the global namespace. I recall seeing some patches that do this in some other
project's mingw32 packages, but I can't find the link right now.

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

[Red Hat Bugzilla]

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

--- Comment #8 from Paolo Bonzini  2010-10-11 08:50:23 EDT ---
> Having a separate '-devel' package seems wrong to me. All mingw32 packages are
> essentially '-devel' packages, which is why our packaging guidelines never
> suggest actually creating -devel packages.

If it's done "one off", it sounds wrong and it probably is.

However, if it is done for all packages, there is value in separating the files
that are deployed on a Windows machine, from those that are only needed for
development.  nsiswrapper for example will add dependent DLLs, but even that is
not enough for packages that have configuration files like mingw32-iconv or
mingw32-gtk2.  The only way to get the full list is to use rpm, but that
includes headers as well as pkg-config and libtool files.  But then, you don't
want to deploy gtk-demo.exe together with your application, so it gets brittle
quickly.

This is probably not the right place to discuss it, though.
> The 3rd option would be to try and fix pthreads.h so that it doesn't pollute
> the global namespace.

Yes, that would be nice.  Also, for the sake of completeness a fourth option is
to say "this is a fact of life" and WONTFIX.

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

[Red Hat Bugzilla]

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

--- Comment #9 from Erik van Pienbroek  2011-01-28 10:07:28 EST ---
I'm currently working on a new Fedora feature called the cross compiler
framework. This will be the successor to the MinGW toolchain in Fedora. It will
be based on the mingw-w64 project (instead of the mingw.org one) and will use
gcc 4.6. With this framework it will be possible to easily build binaries for
Win32, Win64 and in the future Mac OS X (depending on legal issues)

For that toolchain I've moved the libgomp pieces from the gcc package to a
separate subpackage. With gcc 4.6 gcc itself doesn't have a hard dependency on 
libgomp anymore. So whenever one tries to install 'mingw32-gcc' or
'mingw32-gcc-c++' the libgomp pieces (and thus pthreads) won't be pulled in any
more. People who really need libgomp support can install the package manually.

I've tried rebuilding all 96 mingw32 packages which are now in Fedora using
this method and everything built succesfully without pulling in libgomp

More details about the cross compiler framework can be found at
https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework and on the Fedora
mingw mailing list

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

[Red Hat Bugzilla]

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

--- Comment #10 from Paolo Bonzini  2011-01-29 09:32:43 EST ---
I believe gcc should have a hard dependency on libgomp.  Installing the
compiler should bring in all the libraries required to build programs running
with that compiler.

See for example the native package

# rpm -q --requires gcc | grep libgomp
libgomp >= 4.1.2-48.el5

Note that it doesn't require a libgomp.so.1() package, which means that no
executable in the GCC package actually requires libgomp.  It is only present as
a dependency, because it is needed for _users_ of GCC.

Doing things differently in the mingw32 toolchain seems very, very wrong to me.
 I believe WONTFIX is the best solution for this bug if separate -devel
packages are undesired.

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

[Red Hat Bugzilla]

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

Kalev Lember  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |CLOSED
            Version|13                          |rawhide
         Resolution|                            |RAWHIDE
        Last Closed|                            |2011-05-12 13:25:08

--- Comment #11 from Kalev Lember  2011-05-12 13:25:08 EDT ---
I just built mingw32-pthreads-2.8.0-15.20110511cvs.fc16 for rawhide which
should fix the issues mentioned in bug #599227. I am hoping that the
<pthread.h> header is now in good enough condition so that it's no longer an
issue if gcc install drags it in.

Closing the ticket, thanks. Please mention in bug #599227 if there are any more
issues with the pthread.h header.

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

[Red Hat Bugzilla]

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

Bug 599567 depends on bug 641423, which changed state.

Bug 641423 Summary: mingw32-gcc installs files both inside and outside the sysroot
https://bugzilla.redhat.com/show_bug.cgi?id=641423

What    |Old Value                   |New Value
----------------------------------------------------------------------------
         Resolution|                            |WONTFIX
             Status|NEW                         |CLOSED
         Resolution|WONTFIX                     |
             Status|CLOSED                      |ASSIGNED

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

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=599567
Bug 599567 depends on bug 641423, which changed state.

Bug 641423 Summary: mingw32-gcc installs files both inside and outside the sysroot
https://bugzilla.redhat.com/show_bug.cgi?id=641423

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |CLOSED
         Resolution|---                         |EOL