missing lipmp3lame with openshot

[Michael Powell]

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

-Mike