[LAU] Migrating to 64-bit

[Ken Restivo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jun 17, 2007 at 10:35:51PM -0500, Jack O'Quin wrote:
> On 6/17/07, Ken Restivo <ken at restivo.org> wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On Sun, Jun 17, 2007 at 07:12:54AM -0500, Jack O'Quin wrote:
> >> On 6/17/07, Tim Blechmann <tim at klingt.org> wrote:
> >> >On Sat, 2007-06-16 at 22:41 -0400, carmen wrote:
> >> >> On Sat Jun 16, 2007 at 10:30:48PM -0400, Brett W. McCoy wrote:
> >> >> >  I am getting a 64-bit system later this week and will be installing
> >> >> >  Fedora Core 6 x64 and it will be replacing my current studio DAW,
> >> >> and
> >> >> >  I will be mocing my Delta1010 audio interface over to this new
> >> >> machine
> >> >> >  also. Are there any general 'gotchas' with regard to Linux audio
> >> >> and
> >> >> >  64-bit hardware?
> >> >>
> >> >> not with the hardware. with the software, the VM based scientific
> >> >> audio stuff tends to be broken - at least SCLang, PD, and Chuck. not
> >> >> sure about CSound. so if youre into that stuff, youll need a 32bit
> >> >> chroot. or you could control scserver from haskell or scheme...
> >> >
> >> >is it possible to connect to a 64-bit jack from within a 32-bit chroot?
> >>
> >> No.
> >>
> >> Maybe someday, but it's hard and has not been high-priority.
> >
> >Something that is on my TO-DO list but is likely never to get done, is to 
> >create a bi-arch Debian package of jackd and a couple of its dependencies. 
> >Then, one may build and run ChucK or SClang using 32-bit libjack, without 
> >a chroot.
> >
> >This is how many non-64-bit-safe programs run today.
> >
> >        $  find /usr/lib32/ -type f   | wc -l
> >        714
> >
> >So, on my Intel Core 2 Duo Debian Sid system, roughly 714 libraries have 
> >32-bit alternate versions, for use by apps that are not 64-bit safe. This 
> >is a tiny percentage compared to the 64-bit libraries, by the way:
> >
> >        $  find /usr/lib64/ -type f   | wc -l
> >        13443
> >
> >But, I'd propose that a simultaneous installation of 64-bit and 32-bit 
> >versions of libjack, each in their appropriate location in /usr/lib32 and 
> >/usr/lib64, would be cleaner and more transparent for the user than 
> >creating chroots and such.
> 
> There is no point in doing all that until we release a version
> of jackd that can handle both 32-bit and 64-bit clients accessing
> the same shared memory segments.  Right now that is not
> possible.  There are some pointers, for example, in shared
> memory.  That will not work and must be changed.  The jackd
> modifications required are doable (IMHO), but definitely not
> easy.
> 
> To date, there have been no large number of requests on
> jackit-devel or on LAU for this feature.  So, people tend
> to classify it as a post-1.0 work item.

Thanks.

Hmm. If there are issues with pointer size, I'd expect that a 32-bit chroot wouldn't work either.

The correct solution would be to fix the languages to make them 64-bit safe, but as you know that is a non-trivial exercise.

I will make a note in to try these languages again sometime in 2009, and see if by then they either are 64-bit safe or JACK would be able to accomodate them with concurrent use of 32-bit/64-bit libraries at that time.

Thanks again!

- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGdhcve8HF+6xeOIcRAjjuAJ98gj7xo+hBZnXxy4pB9t6C4YJiSgCggyQP
AftRKJWGqXCNT/A8ACImbiw=
=tsXS
-----END PGP SIGNATURE-----