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. 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. > 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 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? >> 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 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. -- +-DRD-+ ------------------------------------------------------------------------------ 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
