[LAU] Migrating to 64-bit

[Ken Restivo]

-----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.

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

iD8DBQFGdWPme8HF+6xeOIcRAq0fAKDG99ruJUO3ly9mOTSohfTTuh/lnACdE0+G
Z6T1sumB0ckODcOz01D5zmo=
=ldpp
-----END PGP SIGNATURE-----