Red Hat Bugzilla – Bug 599567
mingw32-gcc should not drag in pthreads.h because it's buggy
Last modified: 2011-05-12 13:25:08 EDT
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):
Steps to Reproduce:
1. Install mingw32-gcc
mingw32-pthreads gets sucked in as a required dependency to the cross-compiler.
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).
See also this thread in the libvirt list:
The dependency is brought in by libgomp, see bug 641423.
... 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.
The mingw32-pthreads dependency seems to be introduced by this commit http://pkgs.fedoraproject.org/gitweb/?p=mingw32-gcc.git;a=commitdiff;h=4d4930390c5e7e7433610378c8d68527e57597fd 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?
> 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).
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
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.
> 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.
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
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.
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.