On 28.02.2011 19:06, Dan Dennedy wrote: > On Mon, Feb 28, 2011 at 8:23 AM, Simon A. Eugster<granjow at gmail.com> > wrote: >> On 28 February 2011 01:26, Dan Dennedy<dan at dennedy.org> wrote: >>> On Sun, Feb 27, 2011 at 1:47 PM, Simon A. Eugster<granjow at gmail.com> >>> wrote: >>>> On 27 February 2011 22:40, Dan Dennedy<dan at dennedy.org> wrote: >>>>> On Sun, Feb 27, 2011 at 1:01 PM, Simon A. Eugster<granjow at gmail.com> >>>>> wrote: >>>>>> Hey Dan, >>>>>> >>>>>> Just had someone on IRC who tried to compile MLT. It failed on >>>>>> actually everything, the reason was that libc6-dev was missing. Is it >>>>>> possible to add a check for this when configuring MLT? It's not >>>>>> important, but nice to have :) >>>>> >>>>> Not interested personally. IMO, the build does not need to >>>>> idiot-proof. Interested parties are welcome to submit a patch. >>>> >>>> Agree. I was too fast anyway, installing libc6-dev did not solve the >>>> problem unfortunately. >>>> http://pastebin.com/sxUS9A5C >>>> This is now beyond my knowledge ;) >>> >>> They are using the mlt --avformat-svn option with a whole bunch of >>> ffmpeg --enable options within the mlt --avformat-svn-options but not >>> enough libs specified in --avformat-ldextra. Basically, trying to >>> advanced options described here, but not understanding what to do: >>> http://www.mltframework.org/twiki/bin/view/MLT/BuildTips >> >> He was following the instructions on our download page, and > > I was mistaken about his using --avformat-svn. Reviewing the log > again, it appears to be statically linking to > /usr/local/lib/libavcodec.a et al, and obviously it is missing all of > the LDFLAGS that pkg-config normally provides. > >> http://ubuntuforums.org/showthread.php?t=786095 >> for ubuntu. Which are the bad flags there? > > Ah, here is the reason. That page does not use --enable-shared, which > is probably a good thing because then you do not update libraries of > dependent packages without the management provided by packages. Those > instructions are probably a decent way to get more current versions of > the ffmpeg utilities without overwriting shared libs from packages; > however, as you can see it is still installing the static libs to > /usr/local and causing grief for building other software from source. > I see there are 154 pages on that thread, which tells us that a lot of > people are screwing up their systems. Surely somewhere in there is > advice from someone saying to use --enable-shared and --prefix=/usr - > sigh.
Ok, I read a little more about shared libraries, and I think I understand this part now. And also why it is not good to install shared libraries to /usr/local when there already are some in /usr ... > I consider the approach we suggest on kdenlive.org installing-source > irresponsible due to the usage of prefix=/usr for ffmpeg and mlt. Yes, > it will get it onto a person's system so they can check it out but in > an unmanaged fashion that is hostile to other software sharing the > same dependencies. Still, it would be nice to provide something like > this in addition to the build script because some want to understand > what is going on, and it can help new developers. As for developers, I > do not know how you guys do it, but I use a combination of > --prefix=$HOME and environment variables. So far my way was the one described in the manuals: Install everything to /usr. With the disadvantage that the ffmpeg installation was not recognized and trying to install other programs that depend on ffmpeg would cause the package manager to replace my version (so I did not install other programs). >> Something I noticed, we says that libavformat-dev/libswscale-dev/... >> is required, but the ubuntu page does not. Is this related to this >> problem? > > Heh, yeah, first we guide the user to install ffmpeg from source into > /usr. Then, we have them install libavformat-dev and friends. We could > just drop the ffmpeg from source step and keep the libavformat-dev What I didn't know either before was that libav* and libswscale* was provided by ffmpeg. I've got all of them installed. > dependency on the mlt step. But that still leaves mlt going into /usr. > Perhaps leaving the default /usr/local prefix will suffice and be less > problematic. Can anyone test this in a clean (os installed with its > updates and nothing else manually installed) virtual machine while I > work on documenting the build script? But this would force us to drop the --enable-shared option, if we want to allow package versions of ffmpeg/mlt etc. installed? Regarding VM: I've been trying to get ffmpeg/MLT/kdenlive installed on a clean and updated VM for two or three full days, trying to help some guys in IRC. Failed because I got the same error message as above and also tried lots of wrong things (especially with shared libs). Fortunately barjac was there as well and got the users' systems running :) >>> Probably they should use the kdenlive build script I have posted to >>> the forum - the one from the old kommander wizard that I made to work >>> just in bash. >> >> Forwarded. > > I will be putting together an official page on kdenlive.org based on a > similar script I made recently for melted: > http://www.mltframework.org/twiki/bin/view/MLT/BuildScripts > > The advantage of this is that the new script does not default to > /usr/local, but rather a dated subdirectory of ~/kdenlive. All the If I understand correctly then this is the only ?clean? way to still allow packaged versions to be installed. On debian based system checkinstall could install packages -- but then another program might depend on an older version of this package. Regarding env variables and what Pascal mentioned: Does this also work for rendering jobs and executing exported rendering scripts? > dependencies it builds are isolated and resolve perfectly provided you > use the launch script. It would be really cool if we can make a > top-level .desktop file and all generated folders hidden. Then, you > would have something akin to a self-building mac app bundle. Next, if > we can make kdenlive more relocatable, the build folder can be copied > to other machines with the same os but different home directories. > That is possible with melted and OpenShot but not yet Kdenlive. This sounds cool :) Simon
