missing lipmp3lame with openshot

[Gary Aitken]

On 09/06/14 17:25, Michael Powell wrote:
> Gary Aitken wrote:
> 
>> On 09/06/14 16:04, Michael Powell wrote:
>>> Gary Aitken wrote:
>>>
>>>> I'm trying out openshot to learn something about video editing.
>>>> When I go to export, it claims: "The following codec(s) are missing
>>>> from your system: libmp3lame"
>>>>
>>>> The openshot executable is statically linked, and there is a
>>>> libmp3lame.a in /usr/local/lib, as a result of installing
>>>> multimedia/gstreamer-ffmpeg, I think.
>>>>
>>>> Anyhoo, it's not clear to me exactly what the problem is, or how to
>>>> go about finding out.  I presume it is trying to dynamically load
>>>> the library, or trapping an unresolved reference.  I'm pretty rusty
>>>> on ar and ld, so any hints would be appreciated.
>>>>
>>>> Gary
>>>
>>> Note the dependency for  lame-3.99.5_1 in the list below:
>>>
>>> http://www.freebsd.org/cgi/ports.cgi?query=openshot&stype=all&sektion=all
>>>
>>>  Below shows some pertinent info:
>>>
>>> http://svnweb.freebsd.org/ports/head/audio/lame/pkg-plist?revision=354227&view=markup
>>>
>>>  Looks like you need to install lame:
>>>
>>> http://www.freebsd.org/cgi/ports.cgi?query=^lame-3.99.5_1&stype=name
>>>
>>> You can also look at the binary by cd /path/to and ldd
>>> whateverbinary. This will tell you what libs it was built against.
>>
>> I built using "portmaster multimedia/openshot" and ended up with a static
>> executable, which surprises me.  I don't see anything in the Makefile to
>> indicate that.
>> Is there an easy way to force a dynamic build in this case?
>>
>> I've got lame-3.99.5_1 installed:
>> ~$ pkg info | grep lame
>> lame-3.99.5_1                  Fast MP3 encoder kit
>> twolame-0.3.13_3               MPEG Audio Layer 2 encoder
>>
>> ~$ ls -l /usr/local/lib/* | grep lame
>> -rw-r--r--  1 root   wheel        423218 May 19 00:35
>> /usr/local/lib/libmp3lame.a
>> -rwxr-xr-x  1 root   wheel           939 May 19 00:35
>> /usr/local/lib/libmp3lame.la
>> lrwxr-xr-x  1 root   wheel            19 May 19 00:35
>> /usr/local/lib/libmp3lame.so -> libmp3lame.so.0.0.0
>> lrwxr-xr-x  1 root   wheel            19 May 19 00:35
>> /usr/local/lib/libmp3lame.so.0 -> libmp3lame.so.0.0.0
>> -rwxr-xr-x  1 root   wheel        287312 May 19 00:35
>> /usr/local/lib/libmp3lame.so.0.0.0
>> -rw-r--r--  1 root   wheel        180734 Sep  4 14:35
>> /usr/local/lib/libtwolame.a
>> lrwxr-xr-x  1 root   wheel            19 Sep  4 14:35
>> /usr/local/lib/libtwolame.so -> libtwolame.so.0.0.0
>> lrwxr-xr-x  1 root   wheel            19 Sep  4 14:35
>> /usr/local/lib/libtwolame.so.0 -> libtwolame.so.0.0.0
>> -rwxr-xr-x  1 root   wheel        132931 Sep  4 14:35
>> /usr/local/lib/libtwolame.so.0.0.0
>>
>> other ideas?
> 
> Not much of any, per se. The above would seem to indicate that it did build 
> against libmp3lame. At this juncture the only thing I'm left wondering about 
> is which system, e.g is this a problem wrt to 9.x still using a really old 
> GCC or is it a 10.x situation which has changed to Clang. From what little I 
> know I believe that the ports build guys tried to go through the ports tree 
> and winnow out for further work those which  failed to build, or otherwise 
> had some trouble building with Clang. I seem to recall they wanted reports 
> of such at the time. Don't know if this has any bearing on this particular 
> case, it's just all I can think of...

ah, I think the issue with the static load is that the executable is a
python script...

I see I have way too many pythons installed for comfort:

$ pkg info | grep python
py27-goocanvas-0.14.1_5        GooCanvas python bindings
python-2.7_2,2                 The "meta-port" for the default version of Python interpreter
python2-2_3                    The "meta-port" for version 2 of the Python interpreter
python27-2.7.8_4               Interpreted object-oriented programming language

This may be a result of doing some incremental builds of ports, rather than
everything all at once; or not.  If the above should not normally all be
installed at once, is there an easy way to determine which ports need to be
rebuilt?  The openshot script runs python2.7 which was installed by the 
2.7.8_4 package, but some library it uses may well have been installed by
one of the earlier versions.