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

[Dan Dennedy]

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.

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-+