Re: [Mingw-cross-env-list] Solving the Pthreads issue

[Volker Grabsch]

Dmitry Groshev <address@hidden> schrieb:
> On Tue, May 4, 2010 at 07:45, Volker Grabsch <address@hidden> wrote:
> > This is a very interesting work-around. Thanks for sharing!
> 
> This isn't a "workaround", but instead *THE* one and only documented
> way to use pthreads-win32 as a static library. See here:
> ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-8-0-release/README
> section named "Building the library as a statically linkable library".

Thanks for pointing this out! That puts a different complexion on
the issue. It means that we can't expect any library to work with
static pthreads-win32. So the situation is worse than I initially
thought, and we need to find a good way to handle it.

I see the following options:

    1)  Keep pthreads-win32 static and create compatibility patches for
        all libraries that use it.
    
    2)  Build pthreads-win32 as DLL.

In case 1), we could even try to patch GCC's libgomp accordingly,
which might produce a working OpenMP.

In case 2), note that threading applications already do need a
DLL if they are using C++ exceptions. (It's the "mingwm10.dll"
in case you were wondering.)  So at least for those, it wouldn't
make a difference to include a second DLL.

Nevertheless we'll have to decide whether we want to use Pthreads
more, or whether we still want to avoid Pthreads as much as possible:

        2a) Use Pthreads only where it is really needed, such
            that as few applications as possible depend on the
            Pthreads DLL file.

        2b) Use Pthreads for every library that supports it,
            but doesn't support the win32 threading API directly.

Note that 2a) would require some more libraries to use Pthreads in
ordert to get a defined behaviour, as many libraries use Pthreads
unconditionally whenever they find it. Most libraries just weren't
able to find the static Pthreads without further hints, that's how
I'm currently disabling their Pthreads support.

Independently from that, there is the question on whether to
provide Pthreads as core package, build directly within GCC in
order to get OpenMP support, or wither we should keep it as a
separate package:

    A)  Keep packages "gcc" and "pthreads" separate as they are.

    B)  Entangle "gcc" and "pthreads" in order to try to get
        OpenMP support.

What do you think about that? I'd like to collect as many opinions
as possible.


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR