Re: How to package SuperCollider (or, whats the deal with multiarch)
On Tue, Dec 13, 2005 at 01:53:04PM +0100, Mario Lang wrote:
> SuperCollider is for some reason I am going to explain below a bit
> strange when it comes to porting it to AMD64:
>
> SC consists of two separate programs, the synthesis server (connects to JACK),
> and the language client which executes SCLang code. Both processes
> communicate with each other via UDP (OSC).
>
> For reasons of design and speed vs. space tradeoffs, the language
> *has* to be compiled as a 32bit binary. The 64bit build fails
> at runtime due to pointer size overflows. (if anyone wants to know
> more about it, the main reason for this is that SCLang uses a kind
> of slot-mechanism to hold direct and indirect values all in a 64bit
> double, therefore a 64bit pointer + tag does not fit).
Briliant. I just love when programers write non portable code for the
sake of performance. :) What if some future architecture has the
ability to run your code way faster but can't run it because of the
clunky code you decided to write. This has been done many times before
and every single time it eventually became a big problem.
I wonder how hard it would be to change it to using a struct of a 32 and
a 64bit value instead.
> OTOH, the synthesis server builds in 64bit mode, and works nicely. It
> actually has to be built 64bit, since it links to JACK, which
> is most probably a 64bit version on an debian amd64 box...
>
> Now, I can build and install this stuff by hand, simply build the
> server on the system as usual, and build the language client in a sid-ia32
> chroot, do the ld.so.conf magic and symlink sclang. That works
> nicely.
> However, I am kind of wondering how to solve this properly
> when it comes to packaging supercollider?
> I am not up-to-date with how multiarch is exactly ment to work
> these days, would it fit this kind of application?
> If so, whats the proper way to do it, and can this already be done
> with the infrastructure currently in amd64 sid?
Well best case, the code gets cleaned up to be 64bit clean.
Worst case you don't package it for 64bit machines.
Or you can perhaps make the package so that it only builds the "client"
on 32bit systems, and builds the server packages on all systems.
Len Sorensen
Reply to: