Nov 05
Building vlc
Compiling a recent/up-to-date vlc from source, from the latest SVN can be a pain as vlc has LOTS of dependencies. It can be, but it must not. Below I'm goint to present a number of strategies to take the hurdles and get a (more of less) working version of a recent vlc.
I'd like you to note that it might be relevant which version of Linux you are running, for example vlc versions newer than 0.8.6 tend to be not compilable under Debian 4.0 Etch without customizations. That's why Debian Etch has this ancient 0.8.6a version onboard. See and here. The main reason for this is that newer versions of vlc rely on libraries that in turn are not compilable on Etch as well.
Having said this, this post here is my experience compiling vlc on debian 4.0 etch and I got a very recent version of vlc compiled and working!
The UnixCompile vlc docs page should be an excellent guide. Before you read on, read it over at videolan.org!
Strategy 1: Use the build system
Yes, vlc relies on many libs. Knowing this, the vlc developers thankfully added a contribs system in the vlc dirs that makes adding missing libraries, or libriaries you wouldn't like to install on your system, a breeze.
Just in case you don't know, a compile relies on libs available from the environment, your system. To get through the build you can install these libs via apt-get, or tell the compiler to look for the libs in another than the standard location. This location is, eg., the vlc contribs dir. Using the build system will populate this path. It might be useful to have another look at How do I compile stuff or vlc Wiki UnixCompile or ConfigureLine.
Using the build system is, according to the UnixCompile docs, for a "distro that is really bad and doesn't provide the libs", as you normally would install required libs with apt-get build-dep vlc. As Debian Etch is a bit behind, I like to call using the contribs system chosing the "universal approach"...
What's a "contribs system"? Basically it is a subdir in your vlc-sources dir - put all the lib sources you'll need to build vlc here and configure will find them. Or let the "contribs system" do this for you:
- > cd extras/contrib
- > ./bootstrap
- > make
For the guide below, I worked with this git snapshot version from the mirror repo.
Still, keep this quote from here in mind:
The contribs are a way to supplement bad OS/distros which don't provide a simple way to get the libs and development files. It's full of hack and patches and initially designed for MacOSX and win. So it's possible that iconv is not correctly build on unix.
The fribidi error
If the build system approach exits with an error, as it did for me (the fribidi lib just won't compile and broke the make), then you forgot to make sure automake and autoconf is installed (see this thread here). So do:
apt-get install automake autoconf
wipe your vlc build dir and start over. It should run through now. If you still experience fribidi errors, try this thread.
The out of registers error while building ffmpeg
The next error I got was: "error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'" when it got to ffmpeg. First a look at ffmpeg compile problems might help.
The solutions seems to be enable our gcc to handle inline assembler code the way it should and provide enough registers. This seems related to the -O("oh") switch, optimized code and "-fomit-frame-pointer".
Look at what the extras/contrib's make passes to ffmpeg, it should be quite a long ./configure string. Copy it to clipboard, traverse manually into extra/contrib/src/ffmpeg and do: <the ./configure string> plus "-O3" in the extra-cflags category. On my system it looked like:
./configure --prefix=/<some path>/vlc/extras/contrib --extra-cflags="-O3 -I/<some path>/vlc/extras/contrib/include -DNDEBUG -isystem /<some path>/vlc/extras/contrib/include -fomit-frame-pointer" --extra-ldflags="-L/<some path>/vlc/extras/contrib/lib " --enable-libmp3lame --enable-libgsm --enable-pic --disable-debug --enable-gpl --enable-postproc --disable-yasm --disable-ffserver --disable-ffmpeg --disable-ffplay --disable-devices --disable-protocols --disable-network --disable-shared --enable-static && make && make install-libs install-headers
The next error I got was: "libavcodec/x86/h264dsp_mmx.c: In function 'put_h264_qpel4_h_lowpass_3dnow' ... error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'" when it got to ffmpeg. As it seems this much encountered error has to do with the Debian Etch version of gcc and the type of badly written code some gcc versions allow and some don't. Subsequently leading to a lack of registers and other hickups, especially in combination with some code passages related to CPU optimizations, mmx and inline assembler code.
The solutions are manyfold. For some users, raising the number of available registers with the -O ("O as in Oscar") flag solves it, e.g. -O. Others disable frame-pointer with -fomit-frame-pointer to free up another register. Others take PIC out of the mix by omiting the -DPIC -fPIC combo in their configure string. Omitting the flag --enable-pic does the same trick.
A clean solution for me was to disable the mmx optimizations, as my compile hung there, by adding the --disable-mmx flag (via) - although I do not know if this considerably slows down my resulting vlc further down the lane.
Here are the steps:
- Look at what the extras/contrib's make passes to ffmpeg, it should be a quite long ./configure string. Copy it to clipboard
traverse manually into extras/contrib/src/ffmpeg and do: <the copied ./configure string> plus "--disable-mmx".Go to extras/contrib/src and open Makefile. Look for the ffmpeg section, and the options Makefile passes to the ffmpeg compile. Should be around line 1040. And let it look like:
FFMPEGCONF +=
--disable-mmx
--disable-debug
--enable-gpl
--enable-postproc
--disable-ffserver
--disable-ffmpeg
--disable-ffplay
--disable-devices
--disable-protocols
--disable-network
- After that ffmpeg fully compiles. So cd up again to extras/contrib and continue with make.
The libtool dirac version mismatch error
After fixing the ffmpeg issue, a few minutes later compilation stopped again with:
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.
make[3]: *** [libdirac_byteio_la-accessunit_byteio.lo] Error 63
make[3]: Leaving directory `/<somedir>/vlc/extras/contrib/src/dirac/libdirac_byteio'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/<somedir>/vlc/extras/contrib/src/dirac'
make[1]: *** [.dirac] Error 2
make[1]: Leaving directory `/<somedir>/vlc/extras/contrib/src'
make: *** [using-src] Error 2
A quick visit to a search engine brought me to this thread. So:
- cd into extras/contrib/src/dirac
- ./bootstrap which worked its magic on aclocal.m4
- cd ../..
- make
The pangocairo interruption
The next stop was:
checking for PANGOCAIRO... configure: error: Package requirements (pangocairo >= 0.16) were not met:
No package 'pangocairo' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables PANGOCAIRO_CFLAGS
and PANGOCAIRO_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make[1]: *** [.tiger] Error 1
make[1]: Leaving directory `/root/vlc/extras/contrib/src'
make: *** [using-src] Error 2
This is a problem with the newly included libtiger and libkate libs and their dependencies.
Open extras/contrib/src/packages.mak in your editor of choice. Go to thes lines for libkate and libtiger and alter the version variables to require more recent ones, like this:
...
KATE_VERSION=0.3.6
KATE_URL=http://libkate.googlecode.com/files/libkate-$(KATE_VERSION).tar.gz
TIGER_VERSION=0.3.3
...
Then remove the libkate and libtiger build directories from src:
in extras/contrib/src do rm -r libtiger libkate
cd up into extras/contrib and do make
Install the pango + cairo combo:
- First cairo: apt-get install libcairo2 libcairo2-dev
Then pango, which requires glib, most recent on Debian Etch is: apt-get install libglib2.0-dev
then on to pango. One newer release that works with this glib is 1.10, so:
wget http://ftp.gnome.org/pub/GNOME/sources/pango/1.10/pango-1.10.1.tar.gztar xvf pango-1.10.1.tar.gzcd pango-1.10.1.tar.gz./configure && make && make install
- Then pango: apt-get install libpango1.0-0 libpango1.0-dev
- and: no-success!! (Tell me what's wrong!)
Finally giving up on this, I disabled libkate + libtiger from the contribs system by editing extras/contrib/distro.mak and commenting out the line with .kate .tiger. (Alternatively, if you haven't had run ./bootstrap in the contribs before, edit extras/contrib/src/Distributions/<yourdistro>.mak.) Then running make again, the contribs make exited with 'nothing todo'. And so -
The contribs system was complete!
In order to finish the vlc build, do:
- cd up into the vlc root directory, e.g. with cd ../..
- run ./bootstrap which sets the extras/contrib dir as one of the sources for compilation, etc.and spits out files for configure
- run configure, sadly with the --disable-tiger/kate flags: ./configure --disable-tiger --disable-kate
Final glitches
Still, some issues arose. With libiconv I got:
/usr/bin/ld: warning: libiconv.so.2, needed by /usr/local/lib/libvlccore.so.4, not found (try using -rpath or -rpath-link)
/usr/local/lib/libvlccore.so.4: undefined reference to `libiconv_open'
/usr/local/lib/libvlccore.so.4: undefined reference to `libiconv_close'
/usr/local/lib/libvlccore.so.4: undefined reference to `libiconv'
although the contribs system properly supplied it. I found it in extras/contrib/lib and thus added the flag --with-libiconv-prefix=/<path to build dir>/vlc/extras/contrib/lib to my ./configure command. Sometimes it is a bit of a collision between the system's libiconv and the one in the crontribs. One guy suggested moving away libiconv from contribs - may help someone...
Which got me a bit further until: "text/unicode.c:56:3: error: #error No UTF8 charset conversion implemented on this platform!". So, additionally adding the --disable-nls switch, which disables native language support (via), solved this one.
Anyway, after a make && make install you are done.
If you're still stuck, you might want to turn to strategy 2:
Strategy 2: disable unneeded components that break compilation
While running the ./configure && make combination a number of errors will occur if your system - like my Debain 4.0 Etch - is not yet ready for Sid's "unstable" or Lenny's "testing" code. A first reflex might be to try to seperately compile these libs, but don't waste your time - there's a reason why these aren't available, for example Qt4, bonjour/avahi, etc. They just don't compile.
Anyway, on a server system you might not need the glx, skin2, etc. GUI elements of vlc. For example, I just needed the most up-to-date streaming functionalities of vlc and thus could easily neglect the user-interface bells and whistle.
Proceed as follows:
- Download one of the newer source-code tars from the ftp archive: ftp index here
Or even get one of the nightly trunk or branch snapshots: ftp index here - Untar with tar xvf
- cd into the dir and run ./configure
- Systematically note where the configure breaks, then use a search engine to track down which library this error relates to, for example errors regarding avahi point to the bonjour lib. Sometime configure directly tells you what to disable. Or:
- Look for the disable switch with ./configure --help | grep '<a string from the lib's name>'
- Then disable this lib by, e.g., ./configure --disable-bonjour and note additonal errors
Try different versions of the vlc source code, work your way slowly up the version tree. For me, some versions compile with, some only without x264 enabled. Most versions will need disabled libpostproc (used for some transcoding?), glx (part of GUI), skins2 (part of GUI), remoteosd (used when using the remote on screen display), swscale (for transcoding involving rescale), fribidi (an open source multi-language text drawing driver, for subtitles), bonjour (device discovery, like portable mp3 players, related to the avahi daemon/client on Linux), libgcrypt (used to do authentication on remote logins via remote OSD), ...
With some libs like libfaad etc. already installed on my system and this configure command:
./configure --disable-postproc --disable-glx --disable-skins2 --disable-remoteosd --disable-swscale --disable-fribidi --disable-bonjour --disable-libgcrypt --disable-xcb --disable-v4l2
... I was able tobuild vlc-1.1.0 Yellow Bastard on my Debian Etch / Debian 4.0 system - although it threw a slew of ugly warnings on compile time and later when executed - probably that's why it's called Yellow Bastard. A previous 0.9.9a Grishenko build ran much smoother...
Some would argue these no-gui vlcs are cripled, but they are sufficient for a (my) server usage.
Update 2010-09-17:
Since this writeup, I upgraded my Debian to lenny and was presented with the error "LibVLC has detected an unusable buggy GNU/libc version. Please update to version 2.8 or newer" when starting vlc. I thought recompiling a fresher vlc would solve this. It didn't. But I ended up with a newer built of vlc, so for anyone interested:
- downloaded 1.1.4 from here
- and used a new set of disable switches on ./configure:
./configure --disable-nls --disable-mozilla --disable-lua --disable-postproc --disable-xcb --disable-skins2 --disable-libgcrypt --disable-remoteosd - then make && make install
Strategy 3: Building an older version (checkout a tag version of vlc from git)
Of course, our aim is to get a newer version than 0.8.9a on Etch, but even small victories might help here, as the Janus release is especially in streaming and transcoding - due to patents (Debian!) - in regards to encoders (mp3,wma) severly "broken". A cure could be to compile a not-so-recent version. Get it, as shown above, as a git-snapshot from the ftp server or via git directly:
git clone git://git.videolan.org/vlc.git vlc-git cd vlc-git git checkout -b '<some name for this action>' <tag>
In essence, you get the whole repository, cd into it, then revert it to an older version. A bit of explanation here. You can get a list of available tags via "git tag -l" after cd into the repository.
Although vlc relies on git as version control, for reference, here is the post on how to checkout older versions from svn.
Strategy 4: desperately search for readily build vlc packages around the web
Some users did the hard work for you and provide packages of their compile results. For example, this site gives advice on how to get the amd64 package of a 0.9.8a vlc. Anyway, this advice here provided as 'untested' since it didn't help me.