Hi,
As you may know we currently have a package in the Fedora MinGW package collection named mingw-pthreads. This is a library which implements the pthreads API. Internally it wraps the pthreads API to native Win32 API threading functions. This library can be used to allow more easy porting of applications to Windows.
Currently this implementation of the pthreads API lacks certain features which prevent it from being used by gcc to enable certain modern C++11 features.
Therefore upstream mingw-w64 developers have been working on a new pthreads library which resolves these shortcomings in the original pthreads-win32 library. This new library is called winpthreads and is hosted on the mingw-w64 SVN repository. When using winpthreads as default pthreads API implementation we can enable features like std::thread in gcc.
The mingw-w64 developers have recently moved the winpthreads library from the 'experimental' branch to the 'trunk' branch to give it more exposure for testing. As our mingw toolchain is based on mingw-w64 trunk snapshots we should consider using winpthreads.
For Fedora 20 (scheduled fall 2013) I'm considering to replace the old mingw-pthreads package with the winpthreads library and enabling C++11 features like std::thread in gcc
However there is one big downside to this. Once we tell gcc to use winpthreads (or better said: the configure flag --enable-threads=posix) it will cause all binaries which are built using this compiler to automatically depend on the winpthreads shared library (DLL). Even when you build a simple 'hello world' you'll also need to redistribute the winpthreads DLL along with your program to be able to execute it.
We could perform this migration in two separate steps: 1. replace the old pthreads-win32 implementation with winpthreads and have all pthreads-using packages rebuilt against it 2. build mingw-gcc with --enable-threads=posix
Step 1 only affects packages which directly use pthreads. Step 2 is needed to allow applications to use C++11 std::thread
What are your thoughts about introducing winpthreads in Fedora and having gcc use it by default? I personally think that Fedora 20 is a good target for this. If it turns out that it causes too much issues then we still have enough time to do the necessary reverts well before Fedora 20 is released (fall 2013).
Regards,
Erik van Pienbroek
Erik van Pienbroek schreef op wo 24-04-2013 om 20:13 [+0200]:
What are your thoughts about introducing winpthreads in Fedora and having gcc use it by default? I personally think that Fedora 20 is a good target for this. If it turns out that it causes too much issues then we still have enough time to do the necessary reverts well before Fedora 20 is released (fall 2013).
Does nobody have an opinion about this proposal?
I have one package that this might affect, but I won't know for sure how it affects it until the feature is introduced. Currently in mingw-clucene I have threading disabled on 64-bit platforms because of issues with linking it against the existing threads library. Once a new threading library is introduced I would have to test build against that to see if it fixes the 64-bit problem and/or if it introduces additional problems.
I'm in favor of improved threads, though, as a general thing!
--Greg
On Mon, Apr 29, 2013 at 5:57 AM, Erik van Pienbroek erik@vanpienbroek.nlwrote:
Erik van Pienbroek schreef op wo 24-04-2013 om 20:13 [+0200]:
What are your thoughts about introducing winpthreads in Fedora and having gcc use it by default? I personally think that Fedora 20 is a good target for this. If it turns out that it causes too much issues then we still have enough time to do the necessary reverts well before Fedora 20 is released (fall 2013).
Does nobody have an opinion about this proposal?
mingw mailing list mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/mingw
On Wed, Apr 24, 2013 at 8:13 AM, Erik van Pienbroek erik@vanpienbroek.nl wrote:
However there is one big downside to this. Once we tell gcc to use winpthreads (or better said: the configure flag --enable-threads=posix) it will cause all binaries which are built using this compiler to automatically depend on the winpthreads shared library (DLL). Even when you build a simple 'hello world' you'll also need to redistribute the winpthreads DLL along with your program to be able to execute it.
Is there a runtime switch to gcc that tells it not to link in winpthreads? It seems kind of silly to have to link to a threading library when you aren't using threads.
On 04/29/2013 09:17 AM, NightStrike wrote:
Is there a runtime switch to gcc that tells it not to link in winpthreads? It seems kind of silly to have to link to a threading library when you aren't using threads.
That is my only complaint as well, although the times I'll use it will only be when I need the DLL.
On Mon, Apr 29, 2013 at 4:24 AM, Michael Cronenworth mike@cchtml.com wrote:
On 04/29/2013 09:17 AM, NightStrike wrote:
Is there a runtime switch to gcc that tells it not to link in winpthreads? It seems kind of silly to have to link to a threading library when you aren't using threads.
That is my only complaint as well, although the times I'll use it will only be when I need the DLL.
andoni on IRC pointed out the -no-pthread option. You can pass this to the gcc front end to prevent automatically linking in libpthread when you don't need it.
I still am baffled why this target would default the pthread linking option to always on, even when -pthread is not specified. This seems like an upstream gcc bug.
NightStrike schreef op ma 29-04-2013 om 05:27 [-1000]:
I still am baffled why this target would default the pthread linking option to always on, even when -pthread is not specified. This seems like an upstream gcc bug.
I just did some testing with a winpthreads-based toolchain to find out more about what rumors are true and which ones are bogus. Here are my conclusions so far:
* When gcc is built with --enable-threads=posix then it causes libgcc_s_sjlj-1.dll (win32), libgcc_s_seh-1.dll (win64) and libstdc++-6.dll to start depending on libwinpthread-1.dll * A simple 'hello world' written in C and compiled with gcc does NOT have additional dependencies other than native win32 dlls * A simple 'hello world' written in C and compiled with g++ does depend on libgcc_s_sjlj-1.dll/libgcc_s_seh-1.dll and therefore also depends on libwinpthread-1.dll * A simple 'hello world' written in C++ and compiled with g++ depends on both libgcc_s_sjlj-1.dll / libgcc_s_seh-1.dll and libstdc++-6.dll. Both also depend on libwinpthreads-1.dll
So we can conclude that pure C programs build fine without introducing an additional dependency on libwinpthreads-1.dll.
When your program already depends on either libgcc_s_sjlj-1.dll / libgcc_s_seh-1.dll or libstdc++-6.dll then it will automatically have a additional dependency on libwinpthreads-1.dll even when your program doesn't use posix threads.
In Fedora we've currently got 142 binary RPMs which depend on libgcc_s_sjlj-1.dll (win32) and 45 binary RPMs which depend on libgcc_s_seh-1.dll (win64). Once we flip the switch on the gcc side it will cause all these packages to have an additional dependency on libwinpthreads-1.dll.
I don't know if it is possible to teach gcc to have the libgcc_s_sjlj-1.dll / libgcc_s_seh-1.dll and libstdc++-6.dll libraries only depend on libwinpthread-1.dll when '-pthread' is given (perhaps using delay-load or something similar). That question would have to be asked to people who are more familiar with the gcc internals.
Regards,
Erik van Pienbroek
Erik van Pienbroek schreef op wo 24-04-2013 om 20:13 [+0200]:
For Fedora 20 (scheduled fall 2013) I'm considering to replace the old mingw-pthreads package with the winpthreads library and enabling C++11 features like std::thread in gcc
The package review for mingw-winpthreads has just completed so we can introduce winpthreads in Fedora now. However, the test mass rebuild which was completed earlier today has shown that 5 packages failed to build against winpthreads. Therefore I want to resolve these first (together with upstream) and once all issues are resolved we can continue with the real introduction of winpthreads in Fedora.
The current plan for the introduction of winpthreads is: 1. Perform a test mass rebuild using winpthreads (done) 2. Identify and resolve FTBFS packages 3. Import and build mingw-winpthreads in Fedora rawhide 4. Build mingw-headers with the flag bundle_dummy_pthread_headers set to 0 (to prevent a file conflict with pthread_time.h and pthread_unistd.h 5. Rebuild mingw-gcc 6. Rebuild all packages which depend on the old mingw-pthreads package 7. Deprecate mingw-pthreads 8. Block mingw-pthreads from the distribution (Fedora rel-eng)
The question whether to enable support for posix threads in mingw-gcc (for C++11 std::thread support) can be discussed after the above steps are completed.
Regards,
Erik van Pienbroek
Erik van Pienbroek schreef op wo 24-04-2013 om 20:13 [+0200]:
For Fedora 20 (scheduled fall 2013) I'm considering to replace the old mingw-pthreads package with the winpthreads library and enabling C++11 features like std::thread in gcc
We could perform this migration in two separate steps:
- replace the old pthreads-win32 implementation with winpthreads and have all pthreads-using packages rebuilt against it
- build mingw-gcc with --enable-threads=posix
Step 1 only affects packages which directly use pthreads. Step 2 is needed to allow applications to use C++11 std::thread
Hi everybody,
It's been a while since this subject was first brought up. Upstream mingw-w64 developers are about to release mingw-w64 v3 which includes winpthreads (as optional library) any day now. In the last couple of days I've been helping out upstream mingw-w64 developers with identifying and resolving the last known build issues, including all winpthreads related build issues.
Everything seems to be in a good shape now so that brings us to the question what to do next.
Officially we're already past the Fedora 20 feature submission freeze, so we won't be able to announce the introduction of mingw-w64 v3.0 and winpthreads using the Fedora 20 features list any more: https://fedoraproject.org/wiki/Releases/20/ChangeSet Due to this we won't be able to give this change full media exposure, but other than that it shouldn't do us any harm.
Here is what I would like to propose:
For Fedora 20 and rawhide (F21): - Update to mingw-w64 v3.0 once it gets released - Introduce winpthreads and retire pthreads-win32 - Rebuild all packages which depend on pthreads-win32 (so that they start using winpthreads)
For rawhide only (F21): - Build mingw-gcc with --enable-threads=posix
If there's a demand to also enable std::thread support in Fedora 20's mingw-gcc then it can be considered, but it may require a mass rebuild which is harder to achieve given that Fedora 20 is already using the regular Fedora updates infrastructure and updates have to be pushed manually.
If no complaints are posted on this mailing list before this Monday evening I'll apply the proposed changes to both rawhide and F20.
Regards,
Erik
-
Erik van Pienbroek -
Greg Hellings -
Michael Cronenworth -
NightStrike