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.vin...@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 RalfD > -- Fernando _______________________________________________ Cmdist mailing list Cmdist@ccrma.stanford.edu http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
