[Kdenlive-devel] mlt-0.2.4 issue

[cjubon]

Thanks for your answers.
>>
>> Kdenlive 0.5 compiled fine, but was crashing immediately after launching
>> it. I tried to test my mlt-0.2.4-install with
>> 'inigo xyz.mpg', and that gave me
>> 'Failed to load plugin: libmlt.so.0.2.3: cannot open shared object file:
>> No such file or directory'
>> I double-checked that it was mlt-0.2.4 that has been installed and that
>> there was no 0.2.3 on the system.
>> Finally I did a
>> ln -s libmlt.so.0.2.4 libmlt.so.0.2.3 (and ln -s libmlt++.so.0.2.4
>> libmlt++.so.0.2.4 which may not be necessary) in /usr/lib/.
>>
>> Now 'inigo xyz.mpg' works fine and kdenlive does so as well.
>>     
To Dan:
>>> OK, just veryify in whatever way you do on gentoo that the package is 
>>> responsible for the file at 'which inigo'
Yes, it is:
simon at maseltov ~ $ which inigo
/usr/bin/inigo
simon at maseltov ~ $ equery belongs /usr/bin/inigo
[ Searching for file(s) /usr/bin/inigo in *... ]
media-libs/mlt-0.2.4 (/usr/bin/inigo)


To Steve:
>>> It sounds to me like you just need to do a revdep-rebuild to fix your 
>>> library issues.  You shouldn't need to symbolically link libraries.
Of course I shouldn't. That's the point. mlt and mlt++ were actually
installed after a complete system upgrade __including__ revdep-rebuild.
I just ran it once again (having temporarily removed the symbolic
links), it doesn't complain ("Dynamic linking on your system is
consistent... ").
>>> Also, there is a kdenlive 0.5 ebuild available in gentoo bugzilla if you 
>>> would rather use ebuilds: http://bugs.gentoo.org/show_bug.cgi?id=188626
>>>
Thanks for the hint, but I'm happy with my installation from sources.
Great work, thank you every one!

To conclude:
>> >Is this the right place to report the issue or should it go to Gentoo bugs?
>>
>>> I think it should be a gentoo bug unless they respond with a problem in our 
>>> build script and the way it interacts with their packaging system.

I filed a bug on gentoo-bugzilla, let's see what they say.

Simon