[FFmpeg-devel] [PATCH] pthread detection on mingw + static pthread

Måns Rullgård mans
Fri Apr 25 09:54:45 CEST 2008


Gianluigi Tiesi <mplayer at netfarm.it> writes:

> On Thu, Apr 24, 2008 at 09:18:35PM +0100, M?ns Rullg?rd wrote:
>> Gianluigi Tiesi <mplayer at netfarm.it> writes:
>> 
>> > On Thu, Apr 24, 2008 at 09:33:29AM +0100, M?ns Rullg?rd wrote:
>> >> > It is necessary, but belongs in a separate patch. It checks not only
>> >> > that the x264_encoder_open symbols exists, but that we can actually
>> >> > link against this library.
>> >> 
>> >> The existing check seems to work just fine over here.  Do you know of
>> >> a real case where it is insufficient?  Besides, if people install
>> >> broken libraries, they can blame themselves.  After all, we don't (and
>> >> can't) verify that libraries we link against actually work.
>> >
>> > where needed -> mingw
>> 
>> Why?
>
> missing uint16_t or uint32_t typedef

That doesn't matter.  The header isn't compiled.

>> > where not needed -> linux (also others, I've not tested)
>> 
>> This I know.
>> 
>> > libfaac uses the same check
>> 
>> I couldn't possibly care less.
> I mean libfaac detection may have same problems than libx264 detection

Whatever problems they have, the solution they come up with is likely
to be wrong.

>> >> This is better than the original patch, but I'm not entirely happy
>> >> with it.  Why can't the static pthread library do this in
>> >> pthread_create() instead?
>> >
>> > just curious but can I ask you the difference with mine?
>> 
>> I don't understand that question.
>> 
>> > the trick it's also required if you use mutex without using threads at all
>> 
>> Why would you use a mutex if you're not using threads?
> e.g. creating a mutex before calling pthread_create()?
>
>> 
>> > the home page:
>> > http://sourceware.org/pthreads-win32/
>> >
>> > you can ask directly to authors, but I doubt
>> > there is a better way to do this
>> 
>> Of course there's a better way.  Have the library entry points do the
>> necessary setup the first time one of them is called.  Feel free to
>> suggest this to the authors.  I'm not going to waste my time.
>
> it's not my problem I'm using the attached patch and I have no problems

It is my problem when the suggested change makes a mess in FFmpeg.
There is no reason this can't be fixed in the pthread library, for the
benefit of everybody.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list