[Ffmpeg-devel] native win32 threads or pthreads-win32?

[herve.flores]

Le 5 oct. 06 ? 09:47, V?ctor Paesa a ?crit :

> Hi,
>> Hmmm... Not one reply... Not even about the "unrecognized option"
>> problem in gcc. Should I make a new thread about this issue  
>> without so
>> many 'win32's written in the subject?
>>
>> Quoting angustia at arrozcru.no-ip.org:
>>
>>> Hello,
>>>
>>> While making the win32 builds, I came across the decision of using
>>> either native win32 threads (w32thread.c), or pthreads, with the
>>> pthreads-win32 library.
>>>
>>> The builds at http://ffdshow.faireal.net/mirror/ffmpeg/ include
>>> pthreads-win32, but I didn't get any answer from celtic druid  
>>> about his
>>> decision.
>>>
>>> Are there any issues that would make me prefer one over the  
>>> other, such
>>> as stability or performance?
>>>
>>> Also, there are two issues I would like to remember:
>>> 1. Some gccs not returning error on -pthread unrecognized option.
>>>    http://article.gmane.org/gmane.comp.video.ffmpeg.devel/35180
>>>    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15303
>>>    M?ns, did you take a deeper look into this? I couldn't find any
>>> simple
>>>    solution, and I don't really know what other projects did  
>>> about this.
>>>    Anything besides "don't use gcc versions x to y"?
>>>
>>> 2. When mingw32 is selected (or os2, or beos), their native  
>>> threads are
>>>    automatically used. If pthreads are also chosen, they will  
>>> conflict:
>>>    http://article.gmane.org/gmane.comp.video.ffmpeg.devel/26842
>>>    Would it be ok to only include HAVE_W32THREADS if test  
>>> "$pthreads"
>>> != "yes"?
>>>    (configure, around line 2012).
>>>    I haven't tested this yet. I'll submit a patch when I get this
>>> tested.
>>>    Could this also be a problem with os2 and beos when pthreads are
>>> specified,
>>>    or do they not have any libpthreads?
>>>
>
> The man gcc page says that the -pthread/-pthreads flags are machine
>  dependent options, needed for SPARC, PowerPC, IA-64.
> I can only speak for Cygwin, but in this platform is produces a  
> warning.
>
> We could reduce warning verbosity by setting this flag only in the  
> SPARC,
> PowerPC, IA-64 specific sections of configure.
>
> The man ld page says nothing about these flags, I believe the
> "check_ldflags -pthreads" in configure could be removed.
>
> I am speaking as of gcc 3.4.4 / ld 2.17.50, maybe older versions  
> behave
> differently.
>
> Regards,
> V?ctor Paesa

just for information, -pthreads is broken too with Mac (since some  
months)
there is 274 warnings during compile ("-pthread unrecognize option")
But for Darwin, pthreads are in the lib system, in theory, there is  
no need to an supplementary option (it's supposed to be always linked)

$ nm /usr/lib/libSystem.dylib | grep pthread_create
900e69ce T __pthread_create
90024153 T _pthread_create
9006652f T _pthread_create_suspended_np

There is no option -pthread for Darwin, but during pthreads tests,  
the option nevertheless passed (in hard in configure). As GCC passes  
the test of - pthread (a warning is not regarded as a failure), the  
flag passed then but there would not need any.
On the other hand, the warning break all abilities to use Darwin  
pthreads (ffmpeg didnt use more than 1CPU on my 2CPU hardware since  
some months=theses warnings)

bye


Herv?