[CM] linux-port of OpenMusic

Ralf Mattes rm at seid-online.de
Tue Oct 29 20:28:09 PDT 2013

On Tue, Oct 29, 2013 at 07:24:16PM -0700, Fernando Lopez-Lezcano wrote:
> >On Tue, Oct 29, 2013 at 11:17:09PM +0100, anders.vinjar at bek.no wrote:
> >>The jack-api in use in OM is very simple, and doesnt rely on anything
> >>outside jack.h
> Then dynamically linking against the native build of libjack should
> be more than enough, no need to package .so binaries which will
> always lead to problems (for example, libcelt is required by a
> certain build of libjack but not others - if you use the native
> libjack the distribution will take care of the proper library
> dependencies).

Yes, use the distribution if possible at all.

> >>     R> I'm not shure a 32bit libjack will play nicely with a 64bit
> >>     R> jackd.
> >>
> >>It usually does.  What troubles do you see?
> >
> >None, since I couldn't get OM to run without libcelt. I just speculated, since
> >libjack and jack need to work as a pair (i.e. jackd and libjack need to match)
> >and from toying with jack on ARN I know that there are some struct packing issues.
> Jack needs to be compiled with the -DJACK_32_64 option (at least
> jack2 does - there's also a compile flag but I forget the name),
> that creates structures that can be accessed from the 32 and 64
> worlds without compatibility problems. I needed to do that for
> Planet CCRMA when chuck was 32 bit only and our workstations were
> running 64 bit OSs. A Jack that is built with that option will work
> with 32 bit apps on a 64 bit environment.

Ah - I see. Unfortunately, Debian dropped this flag quite a while ago.
>From the changelog: "Drop mixed 32/64bit builds. Will be replaced by multiarch"
Hmm, I'm not shure this was a good idea ...

 Thanks a lot 

> -- Fernando

More information about the Cmdist mailing list