On Tue, 16 Feb 2010 17:08 -0200, "Cesar Strauss" wrote:
> Since Aaron's gcc 4.4.0, when linking with OpenMP support (-fopenmp),
> the module ends up depending on the pthreads DLL.
> The upstream pthreads-win32 project has the following naming convention:
> * libpthreadGC2.a for the import library
> * pthreadsGC2.dll for the DLL.
> Here, "GC2" means GCC compiler, C cleanup code, soname=2. Other
> combinations are possible.
> When packaging gcc 4.4.0, Aaron made the following change:
> libpthreadGC2.a -> libpthread.a
> This is for -lpthread to work.
> I propose going a step further, and doing:
> pthreadGC2.dll -> libpthread-2.dll
maybe. See below.
> libpthreadGC2.a -> libpthread.dll.a
This *sounds* ok, but I'm not sure. Does the specs file specify
'-lpthread' when %pthread, or does it explicitly list libpthread.a (I
can't check right now)?
> We already made a similar change with our mingw zlib package:
> zlib1.dll -> libz-1.dll
Ah, but that was because the upstream zlib folks SPECIFICALLY request
that if you don't build the DLL *exactly* the way they specify, with
*exactly* the same compiler and options, then you must rename the DLL so
that it doesn't conflict with their official one. (And as their official
one uses STDCALL semantics, IIRC, we pretty much HAVE to build ours
differently, since the default calling convention in the gcc world is
Now, a similar argument may also apply here, but I'm not aware that the
w32-pthread folks have specifically requested this.
I happen to think that yes, if we are going to distribute a binary DLL
that we build, as opposed to simply repackaging the existing binary from
their site, then yes, we ought to give it a name that won't conflict
with the "upstream" version.
The implications are that if anyone builds an OpenMP application using
the new mingw gcc, they'll have to distribute *our* pthread DLL, not the