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

Gianluigi Tiesi mplayer
Tue Apr 20 23:46:49 CEST 2010


On Tue, Apr 20, 2010 at 01:11:31PM -0300, Ramiro Polla wrote:
> On Tue, Apr 20, 2010 at 1:04 PM, Gianluigi Tiesi <mplayer at netfarm.it> wrote:
> > On Mon, Apr 19, 2010 at 11:29:44PM -0300, Ramiro Polla wrote:
> >> this is my latest patch against pthreads-win32 CVS 20091019. compiles
> >> and links and works fine with both gcc and msvc (the later was asked
> >> by an ffms2 dev) and any combination of those 2. what it does is:
> >> - remove the false wsock32 dependency
> >
> > the dep is not false :D
> 
> would you care to reply to
> http://sourceware.org/ml/pthreads-win32/2009/msg00053.html
> with a reproducible testcase then?
> 
> >> - remove the requirement for PTW32_STATIC_LIB to be defined for using
> >> the library in mingw32 (like faac did)
> >> - hint the linker (currently gcc and msvc) to run the initialization
> >> code before main() or DllMain().
> >
> > declspec constructor/destructor
> > are enough, just register pthread process attach/detch
> 
> not if you want msvc interoperability.

I doubt ffmpeg complies with msvc, anyway I think an ifdef even more ugly
would be preferred, attribute contructor/destructor is an exposed feature
while adding directly functions to start and end may be subject to changes

> 
> > also I've made /lib/libpthread.a
> > as:
> >
> > GROUP (-lpthreadGC2 -lws2_32)
> >
> >
> > so it will act like unix

it's a script
I have /lib/libpthreadGC2

but when I link using -lpthread
it reads the .a, the linker detects as script and then it replaces
-lpthread with -lpthreadGC2 -lws2_32

> 
> I'm not sure what that does... could you point me to some
> documentation on the matter?
> 
> >> I'm not sending them upstream myself (busy/lazy), but feel free to
> >> split them up and send them...
> >
> >
> > pthreads_win32 upstream? looks unmaintained
> 
> Pretty stagnant, yes, the 64-bit patches haven't been applied yet, but
> it seems Ross Johnson is still at least following the list.

I hade deadlock problems with the stable release on my win64 build of clamav
but the cvs works fine even if some code is not really 64bit aware
handles are always below 32bit even if the datatype is 64 so you just have luck :)


-- 
Gianluigi Tiesi <sherpya at netfarm.it>
EDP Project Leader
Netfarm S.r.l. - http://www.netfarm.it/
Free Software: http://oss.netfarm.it/



More information about the ffmpeg-devel mailing list