[CLAM] Problems using jackdmp instead of jackd on OSX

Stéphane Letz letz at grame.fr
Sun Feb 4 00:46:56 PST 2007


Le 4 févr. 07 à 00:10, David García Garzón a écrit :

> On Saturday 03 February 2007 21:49:53 Stéphane Letz wrote:
>> Le 3 févr. 07 à 21:12, David García Garzón a écrit :
>>> Which
>>> platform are you talking about?
>>
>> OSX....
>>
>>> - Mac: is linked dynamically but the library is packaged on the
>>> bundle. The
>>> effect is like static linking but you could change the bundle.
>>
>> OK. Redirecting to the libjackmp.dylib solved the problem
>
> How? You used install_name_tool, didn't you?

I did that "manually", by removing the "libjack.0.dylib" file  
included in CLAM Frameworks hierachy and putting a link to the real  
libjackmp.dylib instead.

>
>> (well I
>> have some problem with mp3 files later on, playing too slow...)
>
> Maybe we could address that problem later, but these are good news  
> if we can
> change
>
>>> We have not tested jackdmp, so any information you could provide is
>>> wellcome.
>>
>> It seems to work, but what would be the good what to package CLAM  
>> then?
>
> I don't know, really. I have very little development experience on  
> the bitten
> apple platform. Not having an standard name or location for  
> libraries, how to
> say the application: 'link whatever jack you find at runtime'?  
> Anything
> similar to the soname?

As I undersand xx.dylib on OSX are quite similar to xx.so files on  
Linux.  System libraries are in /usr/lib and additional one usually  
in /usr/local/lib.
The issue is that CLAM is currently distributed with a embeded  
libjack (to simplify packaking issue i guess) and thus cannot take  
the libjack version that would be otherwise installed.

Stephane




More information about the clam-users mailing list