In a comment to my previous post about the VLC media player where I announced packages for VLC 2.0.0, Nille asked if I could explain a bit more about the SlackBuild script I use to create these packages.
In my scripts, I sometimes hide interesting side-tracks or shortcuts which you would not notice if you just run the script and wait patiently until the packages have been created.
The VLC SlackBuild script is huge. Apart from VLC sources, it also compiles over 50 (fifty!) other libraries and embeds them into the VLC package. This makes VLC such a versatile media player – it supports many media formats and input sources, has audio visualisation inputs and other cool stuff.
The penalty for having such a big script, is that compiling it all takes quite a bit of time. And if you just want to update VLC to a newer snapshot, it is aggravating when the script also recompiles all of the other internal dependencies. Furthermore, in order to compile the browser plugin, the script needs Mozilla’s xulrunner libraries. Since Slackware does not ship those, the xulrunner SDK has to be compiled as well and that is time-consuming- only to be thrown away after the compilation has ended.
I added a few pieces of code which allow me to considerably shorten the compilation time of my VLC packages.
- Allow the use of a tarball containing a pre-built xulrunner SDK
- Allow the use of a tarball containing prebuilt “contribs”, i.e. all the internal libraries VLC depends on
Let me explain both.
Pre-compiled mozilla SDK.
If you run the vlc.SlackBuild, and enable the creation of the browser plugin “npapi-vlc” (this is enabled by default in the script) then the SlackBuild script will first compile the xulrunner SDK. This takes a long, long time. So, in order to speed things up, the script will look for a pre-compiled version of the xulrunner SDK in the directory containing “vlc.SlackBuild” and use that instead if available. You can find this SDK tarball after the xulrunner compilation has ended; check the “./dist/sdk” subdirectory in the xulrunner source directory (normally that would be something like “/tmp/build/tmp-vlc/mozilla-<someversion>/dist/sdk/“) and copy the file “xulrunner-*.sdk.tar.bz2” you’ll find there back into the directory containing vlc.SlackBuild. Next time you run vlc.SlackBuild, it will extract and use the contents of that SDK file instead of compiling the SDK all over again. Big timesaver!
Pre-compiled contribs.
I usually update the internal libraries (the VLC developers call them the “contribs”) only when there is a reason. For instance, when VLC requires a newer version of such a library, or because a newer version brings speed improvements (think of ffmpeg). But inbetween minor releases of VLC I usually leave the contribs as they are, and only compile the new VLC sources. In order to save time, the vlc.SlackBuild has a commandline switch which tells it to only build the contribs, but skip the VLC sources. This switch is “–wrapvlcdeps”. If you run the command:
./vlc.SlackBuild –wrapvlcdeps
… then the script will compile all internal libraries, and then “wrap” the compiled contribs into a single tarball in your $OUTPUT directory (which is /tmp by default) with the name “vlc-vlcdeps-$ARCH.tar.bz2“. Here, “$ARCH” is the architecture for which you are compiling (usually i486 or x86_64). Note that this command will not create an actual VLC package! All it does is compile the internal dependencies and wrap those into a tarball for later use.
Now, if you copy that tarball back into the directory which contains vlc.SlackBuild, the script will be able to use its pre-compiled binary contents when it is time to create a VLC package. When you run the following command:
./vlc.SlackBuild –unwrapvlcdeps
… then the script will “unwrap” the contents of the “vlc-vlcdeps” tarball and won’t bother with compiling all those contribs again. Instead, the script will proceed with compiling the VLC sources and creating the final package. Big timesaver!
Note:
You may be aware that I need to compile two versions of VLC for my repositories, thanks to stupid US software patents (Europeans, do not forget to sign the anti-ACTA petition at https://secure.avaaz.org/en/eu_save_the_internet_spread/ !). One version contains code which would violate the US software patents, such as mp3 and aac audio encoders, while the other version is free of software patent issues and therefore free to distribute inside the US. The vlc.SlackBuild script can distinguish between “restricted” and “unrestricted” tarballs containing the “contribs” or vlcdeps as I call them myself. The script has this piece of code:
if [ "${USE_PATENTS}" == "YES" ]; then
DEPSFILE="$SRCDIR/$PRGNAM-vlcdeps_restricted-$ARCH.tar.bz2"
else
DEPSFILE="$SRCDIR/$PRGNAM-vlcdeps_unrestricted-$ARCH.tar.bz2"
fi
[ ! -f $DEPSFILE ] && DEPSFILE="$SRCDIR/$PRGNAM-vlcdeps-$ARCH.tar.bz2"
So, if you too need to create two versions of the package (for instance if you distribute your package inside the US) it is up to you to rename the DEPSFILE “vlc-vlcdeps-$ARCH.tar.bz2” after you created it. You should add the string “restricted” or “unrestricted” to its name depending on whether it contains patented code or is unrestricted.
Have fun! Eric
I use my own build of vlc and I remark that almost all the additional librairies that can be used in vlc can also be used elsewhere.
If I am not wrong it seems that you build them only to include them in vlc. Would not it be possible to make slackware packages with all these libraries ?
This would imply that some Slackware-current packages would need to be upgraded. For example to use the last mkvtoolnix I had to upgrade boost.
@Helios
The reason why I add all these libraries statically into my VLC package is because I do not want to depend on Slackware’s own set of libraries (too old versions or not present at all).
Sure, you can create packages for all the internal dependencies and then dynamically link VLC against all of those. This is exactly the reason why many users of other distributions complain so loudly about VLC: some “yum update” or “apt-get bla” updates such a dependency to an incompatible version and VLC stops working as a result. The ffmpeg package is such a package that you really do not want to link to dynamically.
Eric
Thanks Eric 😀
I think your vlc.SlackBuild is the right way for vlc.
I doesn’t want to install so many packages only to compile and run vlc.
It’s so easy to break things so i need to recompile, i rather use an statically compiled vlc that i know will work as it should.
I used dynamically linked vlc long time ago and it was a pain and a lot of patching.
Like many program uses some of the libraries but new program version needs new versions of some libraries and that will break the other programs that might even not compile against the new library and then i need to start adding patches.
This is actually a big problem with multimedia on Linux.
So thumbs up for your statically compiled vlc.
And everyone is free to compile there own vlc the way they want.
Eric
using 13.37 the new compiled vlc using your slackbuild fails with —
“vlc: error while loading shared libraries: libvlccore.so.4: cannot open shared object file: No such file or directory”
wanna be compiler
john
alleytrotter
@John
That’s what you get when you compile vlc 2.x while the old vlc 1.x is still installed.
Remove the old vlc before you compile the new vlc and all will be fine (this is something which happens because the VLC developers bumped the version of their vlccore library from 4 to 5).
Eric
On 13.37 x86_64. The “restricted_slackbuilds” version of vlc 2.0.0 builds and runs OK using an unedited vlc.SlackBuild. But there are no signs of either xulrunner-*.sdk.tar.bz2 nor vlc-vlcdeps-$ARCH.tar.bz2 anywhere in /tmp/build
I used upgradepkg to install. The previous version was your “vlcgit”; upgradepkg recorded as /var/log/removed_packages/vlc-20110910-x86_64-1alien-upgraded-2012-02-20,22:58:30
Can’t see any error messages in the /tmp/*.log files.
Any ideas why I’m missing the two files?
Cheers,
Peter
My bad Eric
Your are spot on as always
thanks
john
@Peter
If you read my post properly I never mention /tmp/build as the location where you can find these files.
Eric
@Eric. Sorry – I don’t understand. You say above “SlackBuild script will first compile the xulrunner SDK … You can find this SDK tarball after the xulrunner compilation has ended … normally that would be something like “/tmp/build/tmp-vlc/mozilla-/dist/sdk/“”
I find /tmp/build/tmp-vlc/mozilla-1.9.2 but it doesn’t contain dist/sdk. Will put some traces into the vlc.SlackBuild to figure out what’s happening.
Cheers,
Peter
@Eric – vlc.SlackBuild does not detect that javac (jdk-6u25-x86_64-1) is installed when run as root.
I always run SlackBuilds as root, not sudo, so the mozilla plugin didn’t get built.
But it does detect javac when run as sudo.
I hadn’t noticed the message on the 1st line as it almost instantly scrolls off the screen:
+++ NOT building mozilla plugin – Needs Sun JDK from /extra! +++
So the solution for me is to add 1 line near the top of vlc.SlackBuild:
PATH=$PATH:/usr/lib64/java/bin
As a general rule, should SlackBuilds be run as sudo or as root?
Cheers,
Peter
Some further details about javac installation…
dad@dad:~$ which javac
/usr/lib64/java/bin/javac
dad@dad:~$ sudo which javac
/usr/lib64/java/bin/javac
root@dad:/home/dad# whoami
root
root@dad:/home/dad# which javac
which: no javac in (/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin)
root@dad:/home/dad#
dad@dad:/var/log/packages$ grep bin/javac *
jdk-6u25-x86_64-1:usr/lib64/java/bin/javac
@Peter
You have to be root in order to use Slackware’s SlackBuild scripts (also true for mine / those of slackbuilds.org).
You can become root in several ways: logging in as root at the login prompt; or using “su -“.
You should not use “sudo” to start a SlackBuild script, nor should you become root using “su” i.e. without the dash at the end.
Root needs to have a proper working interactive login environment, which means that the script “/etc/profile” must have been executed. The execution of the system profile script adds the bin directory of javac to your $PATH.
When I compile packages, I always login as root directly (not using sudo or su) and javac is always found in my $PATH . If that does not happen for you when you login as root, something is not right in your setup.
Eric