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

[Måns Rullgård]

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