On 28.02.2011 19:06, Dan Dennedy wrote: > On Mon, Feb 28, 2011 at 8:23 AM, Simon A. Eugster<gran...@gmail.com> wrote: >> On 28 February 2011 01:26, Dan Dennedy<d...@dennedy.org> wrote: >>> On Sun, Feb 27, 2011 at 1:47 PM, Simon A. Eugster<gran...@gmail.com> wrote: >>>> On 27 February 2011 22:40, Dan Dennedy<d...@dennedy.org> wrote: >>>>> On Sun, Feb 27, 2011 at 1:01 PM, Simon A. Eugster<gran...@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 ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
