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