Howto: Compile the development version of vlc under the latest Ubuntu release

[andrew.46]

I would even consider mentioning that building the development version of vlc would be better done in a virtual machine, in a clean installation of Raring (this is my own model). Problem being for most is that building / compiling vlc uses a lot of resources and all people do not have this available. Interesting to hear the motivations and methods of those who have followed this guide in the past as well as those who are new...

For myself, I have purpose built a computer so I can experiment with multiple VMs and allocate resources extravagantly. My own motivation for building vlc on onr og these sprawling VMs is the joy gained from building and exploring fine software as well as sharing this exploration with others. For bread and butter media playback I do not use the git version of vlc, I usually use Audacious for audio playback, the svn MPlayer for other files and the release vlc when I am feeling lazy...

[mc4man]

I guess any one person's reasons for building some of these sources will vary - here it's mainly that FFmpeg is more 'active' than Libav & that some sources are 'better' when built off of FFmpeg vs. Libav
(again 'better' may be subjective.

I also use audacious & because it bases off of FFmpeg have taken to building it rather than accept the Debian/Ubuntu version which at times doesn't even include the ffaudio plugin, let alone slightly poorer decoding support when it does have the plugin.
(11.10 never got ffaudio.so, 13.04 didn't till the last moment, (took me being a bit of a pita to get a small patch applied), 13.10 should be ok as it will use Libav9

As far as here I think just a note that if on 64 bit & using FO's guide or similar there could be issues during the install phase. The downside of one compete vlc config, build, install command is that with the exception of libopus the error(s) will only occur during install, the build itself is actually fine.
(for purpose of testing I broke your command after the make. So simply removing the offending packages, re-running the install (checkinstall) sufficed, then any removed could be re-installed

As far as my suggested concerning a static FFmpeg build -
Certainly not my place to do so & likely not in this thread but I do think it's better to keep the includes & static libs somewhere else, they're only needed for the target build(s) & can be linked when building from their 'non-standard' location.
(the same as you're doing with FFmpeg & x264 in this guide by installing to $HOME/

[matt_symes]

Guide bookmarked again.

Thanks for posting this andrew.46

[andrew.46]

As far as here I think just a note that if on 64 bit & using FO's guide or similar there could be issues during the install phase. The downside of one compete vlc config, build, install command is that with the exception of libopus the error(s) will only occur during install, the build itself is actually fine.
(for purpose of testing I broke your command after the make. So simply removing the offending packages, re-running the install (checkinstall) sufficed, then any removed could be re-installed

I have a 64bit Raring iso so when I have a quiet moment between studies, work and family I shall install FFmpeg from FakeOutdoorsman's guide and then run the vlc guide and see if there can be an easy resolution. Good to see that you hace done most of the work already

[andrew.46]

Guide bookmarked again.

Thanks for posting this andrew.46

Good to see have the guide active again

[andrew.46]

Seems to be 4 sources/packages involved, ffmpeg; libopus; libvpx; (lib)x264

libopus - a static build to /usr/local causes build failure on 'relocation..."
libvpx - a static build to /usr/local causes install/linking error on 'relocation ...'
x264 - a static build to /usr/local causes install/linking error on 'relocation ...'
ffmpeg - a static build to /usr/local causes install/linking error on 'relocation ...'

In the 3 cases of install/linking error, removing those packages just prior to install & all is well (ie. they're not used during the build

I have not as yet created my 64bit VM but a few thoughts have come to me. The FFmpeg guide is not specifically written for Raring and instead tries to cover a few Ubuntu versions with one guide. But for Raring at least half decent versions of libopus (1.0.1) and libvpx (1.1.0) are available in the Raring Repository, libopus development for one is not that frenetic so should easily be suitable, libvpx looks a little busier and a more recent snapshot or release + repository version would be nice. Using Repository versions for these may eliminate 2 errors and I would be curious to then see if manually enabling pic for x264 and FFmpeg in FakeOutdoorsman's guide made the vlc install a little happier. I would have thought that by default the compiler under 64bit ubuntu would do this but I am completely uncertain about this. Certainly under Slackware this must be done manually by adding compiler flags... Would be nice if vlc would ignore these libraries of course.

Sidenote: You will see as well that the Raring yasm has now caught up with recent developments and now ships with 1.2.0 so this may save the compiler a few runs on FakeOutdoorsman's guide

[FakeOutdoorsman]

Thanks for the reminder--I forgot about the next Ubuntu release. I'll try to work on the guide this week.

...and instead tries to cover a few Ubuntu versions with one guide.

That is the result of trying to be efficient/lazy. Looks like it is time to prune the old versions into their own page...or maybe a "latest Ubuntu" type method is in order. However, my ultimate goal is to ditch the system installation and avoid package management and just provide instructions for a local type install. I haven't tested this in a long time. If anyone wants to add this to the FFmpeg guide then please go ahead.

[andrew.46]

Thanks for the reminder--I forgot about the next Ubuntu release. I'll try to work on the guide this week.

I thought you might be listening in

[mc4man]

There are lots of ways around, the ffmpeg build could supply all for the vlc build that's not available in the repo as long as static builds use -fPIC & in many cases the current Ubuntu repo packages are good & neither guide really needs.

But from another perspective that semi-ties one guide to the other & presumes that the current git FFmpeg is good to go on any day with vlc
Also that presumes a user building vlc has also built FFmpeg.

What would happen if vlc builds off of the FFmpeg source in vlc_deps but then links at install to the FFmpeg git build in /usr/local is unknown.(to me

I still think the cleanest way for both is to install static libs & includes elsewhere & only install binaries, man's, ect. to /usr/local/*
(putting aside all the other sources, I believe that if a static ffmpeg is 'fully' installed' to /urs/local then that 's what will be used when vlc is installed, the same may be true for x264

[andrew.46]

I still think the cleanest way for both is to install static libs & includes elsewhere & only install binaries, man's, ect. to /usr/local/*
(putting aside all the other sources, I believe that if a static ffmpeg is 'fully' installed' to /urs/local then that 's what will be used when vlc is installed, the same may be true for x264

I suspect that as usual you are right . I have stepped sideways a little from the issue by recommending that the vlc guide be used in a dedicated VM rather than as part of a standard Ubuntu installation. I have thought about this for a while and it hinges around the release model of FFmpeg, MPlayer and vlc.

1. Both FFmpeg and MPlayer a meant by the developers to be compiled, installed and used from the 'development' tree. Thus it is a worthwhile exercise to attempt to incorporate these into a standard Ubuntu installation and use both for day to day purposes. Hence FakeOutdoorsman's FFmpeg guides and that MPlayer guide.
2. vlc however is intended by the developers to be installed and used from release versions, the development version is intended to be used by developers, the curious and those who love to tinker with fine software to discover and explore new features. Potential for breakage is great and there will be some complication fitting vlc-git into a standard Raring installation.

(I could add that bug reports, suggested additions etc to the development version of vlc can meet a hostile response from some of the vlc developers, unlike MPlayer and FFmpeg developers, but that is perhaps another issue!) So I have added a suggestion to use a dedicated VM for this guide fully expecting that most will ignore this, therefore I am most grateful that you have found a solution to running both guides on a standard Raring installation...