[FFmpeg-devel] [PATCH] --enable-libx264 and --enable-libxvid depend on --enable-pthread
Sat Feb 28 03:38:25 CET 2009
On Fri, Feb 27, 2009 at 04:57:01PM -0800, Jason Garrett-Glaser wrote:
> 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,
User is an idiot
> overwriting their existing
> x264.h. However, they installed a static version.
x264 configure maybe could check for old .so in the target directory and
* delete them unless it installs a new .so (BOFH solution)
* fail and tell the user that he has to either
+ pick a different directory
+ install shared libs too
+ uninstall the existing shared libs there
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel