[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