Proposal: winpthreads support for Fedora 20

[Erik van Pienbroek]

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