[Kdenlive-devel] [Mlt-devel] Check for libc6-dev in the configure script?

Simon A. Eugster simon.eu at gmail.com
Thu Mar 3 08:15:22 UTC 2011


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




More information about the Kdenlive mailing list