[MEncoder-users] Explanation of compiling treatment
L. Lee
llee040 at sbcglobal.net
Thu Aug 9 20:03:22 CEST 2012
Here's one for the open source compiling experts who still use MEncoder. I'm
a Mac OS X user who just upgraded to Mountain Lion (OS X 10.8 - they don't
use "Mac" in front of "OS X" anymore). Since I upgraded to the previous
system version (Lion - 10.7), I've been using a workaround, and now that
I've had to adjust my build steps again for the latest system and developer
tools (command line tools available with Xcode 4.4.1) I'm hoping to get an
explanation for why the workaround is needed.
Under Lion's Xcode tools, I found it necessary to include "--cc=gcc-4.2" for
my configuration step for both ffmpeg (which is included with the svn for
MPlayer) as well as MPlayer itself. With the new Mountain Lion developer
tools, I'm finally able (as well as required) to omit that option. I have a
little multipurpose script that I've been able to use without any serious
changes since I worked it out for Lion that updates source and builds from
that source x264, MEncoder, and ffmpeg.
When I first constructed the method, I discovered that, for some reason, if
I ran "mplayer/ffmpeg make distclean" before building x264, the libavcodec
folder installed when I had built ffmpeg previously, but which wasn't
removed by "ffmpeg make distclean", was resulting in errors that kept x264
from compiling. So, to make it possible to compile x264 whether or not
ffmpeg had already been compiled (because I need x264 installed before I can
build the ffmpeg I want), I started my routine each time with:
sudo rm -r /usr/local/include/libavcodec/
Can anyone why building x264 required removal of this folder when and only
when the ffmpeg folder in the mplayer source folder is either fresh or
nonexistent?
Thanks.
Laine Lee
More information about the MEncoder-users
mailing list