|
At the fear of being flamed let me just say that I have spent two days experimenting, researching, patching, compiling and linking, often under duress but eventually succeeding.
I started from zero and managed to build proper statically linked binaries at the (mostly latest) version of itself and the associated libraries. I hope this may be useful to someone.h
Here is what I set out to do: I wanted not only compiler mplayer/mencoder/ffmpeg/x264 myself but also the various and sundry libraries used by mplayer for all sorts of different purposes. Vorbis/ogg/xvid/png and what not. In the end I came up with the following list of libraries (and their versions):
SDL-1.2.14
bzip2-1.0.5
cvs-1.11.23
expat-2.0.1
faac-1.2.4
faad1 - (Yes, the deprecated version)
ffmpeg
file64_mingw.diff
flac-1.1.0
fontconfig-2.7.3
freetype-2.3.9
fribidi-0.19.2
gpac
jpeg-8
lame-398-2
libbs2b-3.1.0
libcaca-0.99.beta16
libdca-0.0.5
libiconv-1.13.1
libmad-0.15.1b
libmng-1.0.10
libmpcdec-1.2.6
libogg-1.1.4
libpng-1.4.0
libregif-4.1.7
libsndfile-1.0.21
libtheora-1.1.1
libtool-2.2.6
libvorbis-1.2.3
lzo-2.03
mplayer - latest
opencore-amr-0.1.2
pthreads-w32-2-8-0-release
speex-1.2rc1
vorbis-tools-1.2.0
x264 - latest
xvidcore
yasm-0.8.0
zlib-1.2.3
schroedinger-1.0.8
liboil-0.3.16
(You should find all the libraries I used here, at least the ones I could host)
Why all these libraries? You may have noticed if you ever ran the configuration process for mplayer it goes off (for quite some time I may say) and examines what prerequisite libraries are present on your system. The libraries it finds it builds support for in the 'make' process (a word on that later) - those it does not find it does not generate support for. The configure command after completion of its analysis actually lets you know what support it will generate. It is highly unlikely that you have all libraries on your system that all codecs and filters and what-not are supported. There is some highly esoteric stuff in mplayer/mencoder which you will rarely use. On the other hand you probably want subtitle support, x264, pcm, mp3 and xvid - the more common encoders/decoders.
The nice thing about building everything from source is that you can
a.) Implement a fix to a component instantaneously (no waiting for code maintainers, repos or sourceforge providers)
b.) You can add additional features at anyu point in time.
There is also much less of a chance of version conflicts as you may find out.
At the peril of stating a few obvious things here (if you are not a coder yourself or otherwise technically inclined) - we need an environment to build the various part and pieces that make up mplayer. For building under Windows there are essentially three options:
a.) Cygwin - a huge *nix style set of libraries and components which requires a dynamic glue library.
b.) MinGW - A 'miniature' build environment solely destined to allow you to compile code and build components
c.) A Windows native compiler such as MS VS or Borland.
c.) Is really only an option for a small number of libraries. Due to incompatiobilities between many tools, code especially written gor the GCC compiler and its assortment of build tools will not compile soiimply using VS or Borland. There are, however, exceptions. Xvid comes with a VS project and FAAC/FAAD can be easily built using the Microsoft compiler. However, as you can see above, there are many, many more libraries involved and unless you want to engage in a hiuge headache of patching the code to work with say Vistual Studio it is simply not an option.
a.) Is an option but I have in the past run into issues which took me a while to resolve so for this go-around I decided to use b.).
In general you can download MinGW project (and sourceforge link) here:
However, I can only urge you not to start out with that route (albeit, it is possible). There are essentially two reasons for it:
a.) The tools that come with MinGW from this project page are old, very old, very, very old. It comes with version 3.4.5 of the gcc compiler. That is about a decade overdue. This compiler won't do any optimizations for current processors - as a matter of fact, the mplayer configuration process will get very cofnused and indicate something about inttypes.h not found. Well, the messages is incorrect but it fails because the compiler knows nothing about recent machine architectures. I haven't the foggiest clue whyt the MinGW folks distribute a compile from the stone age. You should work with version 4.2.x of gcc.
b.) MinGW distributes many components using the lzma compression format. It may have escaped the project developers that the lzma project has died a long time ago or manybe on of the original lzma developers still sees a need to compress an aditional 5% of size out of a download but otherwise it is a huge pain to find a GUI tool under Windows which supports this format. If you are ever forced to deal with it, try PeaZip.
I could have started off with MinGW as it comes and then proceeded to compile a more recent gcc compiler but I have little faith in this distribution given the desolate state of its toolkit. Compiling gcc itself is a major undertaking which I did not consider essential to what I was trying to accomplish.
Instead I downloaded TDM's GCC/mingw32 Builds from here: http://www.tdragon.net/recentgcc/. This is essentially a MinGW system with a compiler younger than you. Actually, as of this writing it is gcc 4.4 bleeding edge.
The executable will create a directory (by default c:\MinGW) for you and places a variety of files into subfolders. While you can essentially choozse any other name as long as the path does not contain any spaces (please, do not pick "My Documents") I urge you and from here on assume that you have chosen the default.
While this gives you the compiler and some tools it does *not* give you a 'system', a command line where you can execute your commands. For this you want to download msys. Note that the link may change as new releases (unlikely) emerge. Run the installer and when asked where you minGW installation is, enter c:/mingw - Note the forward slash and not the backward slash. You will spend a lot of time scratching your head if you do as none of your commands will be found.
Finally, while not an absolute must, install pkg-config from here. Using pkg-config obviates the need to specify the prefix switch on every configuration requests and in general tracks better where which libraries are located and installed. It can save you some headaches when mplayer reports that this ir that library cannot be found. It is not a requirement but will mkae things a bit easier. If you decide to use pkg-config make sure you set the PKG_CONFIG_PATH as shown below.
This environment allows you to build just about any of the above libraries, it will not let you build faac and faad and I was particularly interested in those. The bootstrapper requires automake and autogen which are per scripts meaning you need Perl. Don't think for a minute you can install Activeperl and make it work with those tools. You could compile Perl yourself but then you could also shoot yourself. Instead, download /msysDTK from here.
Now when you click on the msys icon that has ben placed on your desktop you should see a nice command window which will accept bash shell commands and allows you to run your compiler.
Type 'gcc --version'. You should see something like this:
gcc.exe (TDM-2 mingw32) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
If you get 'Command not found' open your fstab file in the C:\msys\1.0\etc directory. You should see one or more mapping lines. Every line consists of two paths on one line, the first one being a Windows path (c:/minGW) and the second one ythe path as is mapped into your 'MSys' file system (/mingw). Note that there should be no quotes or apostrophes or commas. Also, all Windows paths should have *forward* slashes, no backslashes.
While we are talking about editing MinGW files: Chnces are high you will be editing files with Unix line separators (lines being separated by a single newline character) instead of a newline;/carraiage return combination. If you edit these files with notepad (you can just type 'notepad fstab') you will not see proper line breaks but a lot of gobble-de-gook. I very much suggest you replace your good old notepad with flo's notepad2 or notepad++ (google it). Both of them will serve you well in editing both Windows/Dos and Unix style files whereas Notepad++ is actually a pretty decent program editor. I use it all the time and constantly work across platforms.
Now that you have set up your dive mappings, you should make sure your compiler paths are set properly. By convention all your builds will generate files mostly in three different directories: c/c++ header files, libraries and executables. By default they will be placed into your C:\msys\1.0\local\include, C:\msys\1.0\local\lib and C:\msys\1.0\local\bin directoryies respectively. (I shall refer to them via their mappings 'inside msys' of /local/include, /local/lib and /local/bin).
However, the gcc compiler looks for them by default only in the places /include, /lib and /bin respectively. open up your 'profile' file in the /etc/fstab directory (it is a bash command file which iwll be run every time you open up a msys command window) and add the following two lines:
export CPATH=/local/include
export LIBRARY_PATH=/local/lib
export LD_LIBRARY_PATH=/local/lib/bin
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
This sets environment variables for the compiler and configure process so they will also search these paths when looking for header or library files.
Why do we have to do this? When building the various libraries their interface definitions (header files) and code which we will link agains (the actual libraries) need to be detected by the configure mechanism of all other libraries that reference them. Otherwise you would be building a gazillion libraries but mplayer would still not be able to find them (besides that there are relationships between the libraries themselves and as such they would not build).
Make sure you close and open the command window after having made the change to make the change active.
Type in
echo $CPATH
You should see the path you have defined. If it echoes a blank line, please double check your steps.
The next step is an unfortunate one of having to patcha few minGW files. Actually, everything will compile and build just fine and seem as you were successful - that is until you try to create or play your first file larger than 2GB at which point very strange things will happen. In general the encoded files will not be playable or not play back. The reason is that the integer definitions for io are not quite set up properly in minGW (No, I really don't know why). You can use a patch file attached here but depending on what minGW version you are running and their names and locations it will not apply. Fortunately there are only three files to be patched. (If you know how to use the patch command and don't mind updating the patch names ignore the rest of my comments on the patch):
When you use notepad++ to open file64_mingw.diff you will see three sectiosn for three files, nicely highlighted.
They are /include/io.h, /include/sys/stat.h and /includes/sys/types/h.
The line prefixed with '@@' shows you approximately where you should find the displayed content and the lines prefixed with a '+' are the lines to be inserted. When inserting the lines make sure you get rid of the leading plus sign.
It's really not that hard.
You may be tempted to skip this step but trust me, you will come to regret it. Make sure you patch minGW.
The next step would be retrieving all the source code I showed at the beginning of the article. There are two basic methods of doing so: Either via a source management system or by simply downloading it. So what's the difference? Using the source management system (we are dealing with three different ones here: subversion, cvs and git) you can tape directly into the developer repository. You will be getting bleeding edge code. You also get the benefit of automatically updating related source code files on your computer. For example, when you pull the mplayer/mencoder code from subversion you not only update the mplayer repository but also libavformat, libdvdnav, libpostproc, etc. Once you have pulled down the code once the source management tool knows how to find only that code which has been changed and a subsequent request to get the latest version is very quick. Mplayer is maintained via he subversion system. Fortunately, if you followed the steps above the subversion and cvs commands are already installed in your system. So go ahead, click on your msys icon and then type in
svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
You should see a bunch of file names fly by as they are downloaded to your computer. It may take quite a while on the first time around. Once the download is done go into the mplayer subdirectory and type in
svn update
You can do this whenever you want to grab the latest copy. Chances are that nothing will happen - after all you just downloaded the very latest and greatest. However, if you try again in a few days you will generally find that a few files will have changed. Be forewarned, though: You are getting the bleeding edge. However, considering that the mplayer team is apparently no longer putting out 'releases' you really don't have much of a choice on how to deal with the code. If you find something is broken, talk to the developers on the mailing lists. I have found them to be very helpful and responsive in fixing a bug as long as you provide them with proper diagnistics. When they tell you they have fixed your probalem, just type in svn update again and you have the fix that was just written halfway around the world. Pretty cool, isn't it?
x264 unfortunately uses git as its source management mechanism. You can either try to compile git for minGW (check out mysygit by googling it) or install the Windows version by downloading the installer here http://git-scm.com/. You can then enter the git command prompt (which is unfortunately another than the msys one and will download the code to another location but you can either copy the code into your msys system or use the fstab file to map your paths so msys will point to the git file you have retrieved.
In any case, in your git prompt type in
git clone git://git.videolan.org/x264.git
This will retrieve the latest and greatest x264 code directly from the source repository.
If that sounds like too much hassle to you, you can also find a dialy snapshot here. (Make sure you scroll all the way to the bottom, the code at the top is old).
All of the code you will be dealing with will be in tar or tar.gz (as in gzipped) format. You can unzip all the files you will download by issuing the command
tar -xvf xxxx.tar.gz
where xxxxx.tar.gz is the file that you donwloaded. However, if you prefer a GUI (and I do) I can very much recommend Winrar. The evaluation version is free and when you download the file, simply specify that you wish to open it in Winrar instead of actually locally downloading it. Then, when Winrar opens the file, simply drag the directory it shows into Windows Explorer under C:\msys\1.0\home\Administrator. Every library should have its own subdirectory. Pretty much all libraries will come using a naming convention which indicates whal release level it is. You should maintain that naming convention and not rename it to a generic 'flac' instead of 'flac-1.1.0'. Later on you will be glad you did as you juggle various releases.
All code here (24hourloop) is rar'd which is unusual but then again it targets a Windows audience.
ffmpeg fortunately is also maintained under subversion, so
svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
will get you the latest ffmpeg. Note that the last parameter on the command indicates the directory that will be created to hold the code.
When you retrieve code using the source management system it makes no sense to maintain a 'release level'. Instead, the command will indicated a 'revision level', meaning a number indicating how many times changes have been made in this repository. The higher the number, the more recent the code is. Other than that it has little meaning,
The rest of the code you will simply download from god-knows-where (or here). Actually, this is a good thing. Unlike when dealing with object code it really generally doesn't matter where the code originated. It is perfectly legitimate to grab the latest lame code from a debian distro. Source code is source code and all the code above is smart enough to adapt itself to the actual environment it is being compiled under.
So go ahead and dig up all that source code. Please stick with the version you see above. For example, flac 1.2 would not compile for me under minGW but 1.1 did. But everything you see up there *did* compile. If you run into a particular problem shoot me a line describing your symptoms in the forum at http://www.24hourloop.com and I'll try to help.
Now it gets a bit dicey. If you have worked under Linux before you will have noticed that your 'package manager' (rpm, yum, apt-get, etc.) was smart enough to figure out that you needed a installed before you could install b. Well, with source you are on your own. Fortunately I found that most of the build procedures were rather kind in informing me about dependencies or when they failed to compile it was pretty obvious why. For example, fontconfig will not compile without you having previously compiled freetype. Similarly, libbs2b required libsndfile which requires libvorbis which requires libogg. You see, you are in for somewhat of a journey. But then again, hang in there, you only have to do it once.
So how does this whole compiling work? It essentially consists and dependes on the successful execution of three commands. For each and every library you issue a 'cd' command to enter the directory. (Please don't email me informating me one should really not build in the source tree itself or some other smart-ass remark - I am perfectly aware of that but things will work just fine if you do as I did).
Pretty much every directory will contain an executable file called 'configure' (in minGW like in any other Unix-style environmnet executable files do not need to hae a particular extension to be recognized as executable). You invoke a file in the current directory by prefixing its name with './'. Under Windows you may be used to the convention that you can simply enter the name of the file such as 'configure'. Chances are that will not work but './configure' will.
The configure command will go out and do all sorts of things to determine the environment it is in. Often this consists of writing a mini-program, having the compile translate it and then cghecking the return code to see what happened. That way it can check for the presence of certain header files (remember we updated the search path for those already?) which indicate the presence of libraries that it can eventually link against. But the configuration file is not limited to that - it can really do whatever is necessary to build the proper header file to compile its own code. This is how mplayer optimizes its code for your specific processor.
How long this discovery process takes varies widely - from a couple of seconds to 15 minutes. In rare circumstances the configure command will fail. It will try to tell you why but always also refer you to the log file, configure.log or config.log - the name may vary. If you open up the file and scroll to the bottom you should have an idea on what went wrong. If not, well, try googling or post your question. This is where the tricky part may start.
But the configure file can also accept a number of parameters that customize how the code will be translated or linked. Whatever it does - it creates an input file for the 'make' command. Make is a command which is a sort-of command processor which takes a set of instructions and objectives and according to specific rules executes other programs to do what needs to be done to put your program together. By default you do not provide it with parameters. Simply typing in 'make' will execute the instructions written by the configure command. Typically that involves compiling many programs with an insane amount of parameters. Often it will also spit out a ton of warnings. Do not despair - as long as the process ends you are ok. Sometimes that may not be all too obvious but a careful read of the last few messages should tell you if it aborted or ended.
Once the make completed you now need to cause the make command to install its output into the locations where it can be found by subsequent compiles of other libraries and eventually mplayer's compile. Note that while the source libraries will generally have a version prefix the output will not. bzip for version 2.1.0.5 will be bzip as much as version 2.1.0.3. So in general only one version may be installed at a time.
If you want to uninstall something you installed in this fashion the developers added another 'target' to the make input. If you enter 'make clean' it should remove whatever it installed (but not the source directory). However, this is entirely up to the developers to provide for that and a matter of convention. Worse comes to worst, you'll have to delete it manually. If you want to remove any potential discovery of the configure command and start from scratch you may be able to enter 'make distclean' which should take you back to square one. But again, this is up to the developers of the library and if they deemed it necessary.
So you will be trucking right along and building library after library - It can be soothing to see those lines flash by ...
Inevitably you will run into some problems for a few of those libraries and I wish I had written all of them down ;-). There were only a handful, some of them already addressed by the proper versions you see.
Let me see which ones I remember:
For faac and faad go to the audiocoding.com's download pages. As sad as it sounds those two were the hardest to compile under minGW. For faad you are stuck with the deprecated version. The current one will not compile, period. Deprecated or not - it works fine. For faac, grab the latest snapshot, the other stuff won't build, either. DO NOT USE THE BOOTSTRAPPED CODE. Instead you should be able to bootstrap yourself if you installed the additional tools I outlined further up (I installed msysDTK solely for faac/faad). The process here is slightly differentl. First issue the './bootstrap' command then followed by './configure' and so on. The problem is that the bootstrap command runs all these tools which require Perl and the audiocoding folks tried to make it easy by doing this already for you so you do not have to have. Unfortunately whatever they came up with does not work with minGW.
Audiocoding also provides a Microsoft solution file and if you have Visual Studio (I presume it'll also work with the free (what Micro$oft gives away something for free? - Yes, they do) Express version. While this will produce a proper faac/faad command line tools it does *not* generate a library that mplayer can by statically linked against (Static linking means that you only wind up with a single mplayer/mencoder.exe file that does not require additional dlls).
Static linkage:
You want to make sure that whenever you build any of the libraries you do so with ./configure --enable-static so a version of the library is build that mplayer eventually can include in its executable. Failing to do so will not only leave you with the necessity to maintain shared dlls but may also cause whole libraries to go undetected. Say you built iconv dynamic and then want to build mplayer statically, iconv, fontconfig, freetrype will all not be detected by the mplayer configuration process. If you failed to build libraries statically, go back and issue a make clean before doing a fresh configure/make/make install. Chances are that if you don't, remnants of code will be left around which may configure susbequent configurations.
Another stumbling block was fribidi. When running make you will get
libtool: link: more than one -exported-symbols argument is not allowed.
Simply edit the Makefile in this directory and update the line as shown below:
libfribidi_la_LDFLAGS = -no-undefined -version-info $(LT_VERSION_INFO) \
-export-symbols-regex "^fribidi_.*" #$(am__append_1)
(Note the hash symbol)
After you have fixed this you will get:
/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib -I../charset -I/mingw/include -DMINGW32 -march=k8 -mtune=pentium-mmx -mthreads -O4 -g0 -mms-bitfields -pipe -Wall -ansi -MT fribidi-benchmark.o -MD -MP -MF .deps/fribidi-benchmark.Tpo -c -o fribidi-benchmark.o fribidi-benchmark.c fribidi-benchmark.c: In function `utime': fribidi-benchmark.c:126: error: storage size of 'tb' isn't known fribidi-benchmark.c:126: warning: unused variable `tb' make[2]: *** [fribidi-benchmark.o] Error 1
To fix it, I made the following change for bin/fribidi-benchmark.c:
void
)
{
#if HAVE_SYS_TIMES_H+0
struct tms tb;
times (&tb);
return 0.01 * tb.tms_utime;
#else
return 0.00;
#endif
}
(Thanks to whoever maintains this page for helping with the info).
Just keep running make again and fnally make install.
I vaguely recall that the version of libmad was a bit touchy. Use the version I show and you should be ok.
Xvidcore:
Works slightly differently. There is no configure file but you should find one in the xvidcore\build\generic directory. (Do not give into the temptation of using the files in xvidcore\build\win32). Once you went through the configure/make/make install process find xvidcore.a in you /local/lib directory and rename it to libxvidcore.a. Also, get rid of xvidcore.dll.
SDL:
Although I configured SDL with ./configure --enable-static --disable-shared I kept winding up with a (dynamic) SDL.dll. This seemed to (presumably rightfully) mplayer's configure process and the resulting build depended on the presence of SDL.dll in the target system. There is nothing wrong with that but I presume you would prefer a standalone version, statically linked. I explicitly deleted SDL.dll after building and before configuring mplayer. That allowed mplayer to successfully link statically.
To that end, when configuring libtheoro, specify ./configure --disable-sdltest. I found the test lacking. Even if you have a functioning SDL.dll in your path the test program will not find it and complaing. You can either copy SDL.dll into the libtheora directory where it will be found or skip the whole test by specifying the baove option (which is what I did).
Now that you have built all these wonderful libraries go ahead and build mplayer by issuing the 'configure --enable-static' command. This will take quite a while. The output will indicated what codecs and filters and what-not are supported. If you find that some of the ones you expected to be there do not show up, reconfigure and make those and check again. If they still do not show up, open up the configure log file and try to determine what the configure command was doing to determine the presence of a library. This might give you some important clues as to what you might have missed.
Well, if everything looks ok, do a make && make install and you should have a shiny new mencoder/mplayer version (plus ffmpeg and x264).
Use this guide at your own peril. Not responsible for any combustion inside your computing device. Constructive feedback in regards to any omissions or observations are appreciated.
|
