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

Tue Mar 1 20:37:03 UTC 2011

On Mon, Feb 28, 2011 at 19:06, Dan Dennedy <dan at dennedy.org> 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.
>
> 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?
>
> I use it this way. I have installed the build-dep stuff needed for ffmpeg,
frei0r and mlt, and have simply replaced /usr with /usr/local in every
command line tool. This has the advantage that it's already in the PATH of
all sorts of things, so that most detection scripts (configure, cmake) will
find the libs there with no change. There is one lib that will not be
detected because the version shipping with Kubuntu 10.04 LTS is too old (I
simply dropped the --enable-libx264 flag).

Also, as a beginner step, I would suggest we emphasize the latest version
that is released (i.e. using the version tags for ffmeg, frei0r and mlt) and
that users wander to HEAD only if there are issues. except for kdenlive, as
it is arguably to get the latest greatest that people compile it anyway.

Note that I got this weird error due to this mix: if the user has kdenlive
installed on his system, then it may well occur that he runs kdenlive from
/usr/local/bin, but the config still uses /usr/bin/melt. This mismatch is
strange, as he will see all effects working in the editor, but when
rendering to file or DVD, some of them will not work. It took me some
digging to find this out. One suggestion would be to have melt output the
version of mlt it is compiled with, and comparing that to the version
kdenlive is using, and warn about discrepancy.

>> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20110301/c5058cf4/attachment.html>