[FFmpeg-devel] Fix libx264

Ramiro Polla ramiro.polla
Thu Feb 4 15:45:03 CET 2010

2010/2/4 M?ns Rullg?rd <mans at mansr.com>:
> Ramiro Polla <ramiro.polla at gmail.com> writes:
>> 2010/2/3 M?ns Rullg?rd <mans at mansr.com>:
>>> Felipe Contreras <felipe.contreras at gmail.com> writes:
>>>> I'm getting this error when trying to build with --enable-libx264:
>>>> ---
>>>> gcc -o /tmp/ffconf.Ln1pzlRv /tmp/ffconf.PTBRiOvi.o -lz -lbz2 -lm
>>>> -lmp3lame -lm -lx264 -lm
>>>> /opt/x264/lib/libx264.a(encoder.o): In function `x264_encoder_frame_end':
>>>> encoder.c:(.text+0xe4a): undefined reference to `pthread_join'
>>>> Apparently this only happens when libx264 is built statically. In any
>>>> case, the solution is to add -lpthread.
>>> No, the correct solution is to add the compiler-specific flags
>>> required to link the thread library. ?For gcc this is -pthread, note
>>> no 'l', for other compilers it is often something else.
>> Hmm, according to [1]:
>> -----------------------
>> Standard Libraries
>> The c99 utility shall recognize the following -l operands for standard
>> libraries:
>> [...]
>> -l pthread
>> ? ? This operand shall make visible all functions referenced in
>> <pthread.h> and pthread_kill() and pthread_sigmask() referenced in
>> <signal.h>. An implementation may search this library in the absence
>> of this operand.
>> [...]
>> -----------------------
>> IMO the description for c99 in that page fits our use of gcc -std=c99.
>> So it seems pthread may actually be a library. In that case we should
>> support it. This means it should be put in the correct order so it may
>> be used by another library (in this case more specifically -lx264.
> Your opinion is irrelevant. ?We support some systems where this simply
> doesn't work.

Could you please be more specific as to what "this" is?

More information about the ffmpeg-devel mailing list