[FFmpeg-devel] [PATCH] --enable-libx264 and --enable-libxvid depend on --enable-pthread

Måns Rullgård mans
Sat Feb 28 02:16:50 CET 2009

Jason Garrett-Glaser <darkshikari at gmail.com> writes:

> On Fri, Feb 27, 2009 at 4:53 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
>> Jason Garrett-Glaser <darkshikari at gmail.com> writes:
>>> On that note, anyone have any ideas about how to fix ffmpeg's current
>>> problem with x264? ?If x264.h is current but the x264 library itself
>>> is not, ffmpeg will think the version check succeeded and link itself
>>> to an ancient x264, resulting in random weird segfaults and other such
>>> things. ?I have seen half a dozen people already with this problem in
>>> #ffmpeg.
>> How would we detect this situation? ?If the header is present, and the
>> library can be linked against, we must assume that the installation is
>> correct. ?Users with broken installations can blame themselves.
> I think this happens because of the following situation:
> 1.  User is using $somedistro.  $somedistro keeps a shared x264
> library of version X, an old version.
> 2.  User installs x264 in --prefix=/usr, overwriting their existing
> x264.h.  However, they installed a static version.
> 3.  User configures ffmpeg.  ffmpeg checks the version by checking
> x264.h--not by checking the .so--and because shared linking is
> preferred to static by the linker (by default), the linker will link
> to libx264.X.so instead of libx264.a.
> 4.  Things fail miserably.
> At least that's my theory.

That is a possible scenario, and I would say the user is at fault
here.  There really is nothing we can do to protect ourselves against
this, at least not anything that's worth the effort.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list