[FFmpeg-devel] [RFC] Removing non-pthreads support

[Reimar Döffinger]

On Tue, Apr 20, 2010 at 08:58:43PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > On Tue, Apr 20, 2010 at 08:29:14PM +0100, M?ns Rullg?rd wrote:
> >> > And there is no question it is a maintenance effort, I just think in
> >> > the case of Windows it is a small enough to be justified by the higher
> >> > convenience for users.
> >> 
> >> How is --enable-win32threads more convenient than --enable-pthreads?
> >> The build environments we require come with pthreads already, so
> >> there's no added burden there.
> >
> > Hm, does MinGW include it nowadays?
> 
> I thought it did.  Maybe I'm wrong.
> 
> > The convenience is in being able to easily build a single binary for
> > redistribution, which I though so far is the way most people get Windows
> > binaries for both FFmpeg and MPlayer, but which requires statically linked
> > pthreads which does not seem to work properly.
> > At least that is my understanding of the situation.
> 
> Static pthreads can be fixed.  Being static, it's enough to fix it on
> the system where builds are produced.  Those downloading it don't need
> to care.

That fixed version at least sure won't be included in  MinGW though :-).
Anyway, I don't want to drag this out into an endless discussion,
my point is: I'd prefer to have the native support as long as static
pthreads is a bit questionable, but if there's a known way to fix
static pthreads and we document it somewhere, somehow I'm not going
to insist.