1:13 p.m.
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
5:57 a.m.
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?
7:30 a.m.
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(a)vanpienbroek.nl>wrote:
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
9:17 a.m.
On Wed, Apr 24, 2013 at 8:13 AM, Erik van Pienbroek
<erik(a)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.
9:24 a.m.
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.
10:27 a.m.
On Mon, Apr 29, 2013 at 4:24 AM, Michael Cronenworth <mike(a)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.
7:04 p.m.
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
12:03 p.m.
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
5:06 p.m.
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:
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
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
3882
days inactive
4025
days old
8 comments
4 participants
participants (4)
-
Erik van Pienbroek -
Greg Hellings -
Michael Cronenworth -
NightStrike