eduard.aylon at gmail.com
Mon Sep 11 19:45:23 EDT 2006
I forgot to thank you for finding where the error comes from.
> I am seeing this, too. First, a disclaimer. I've barely gotten into
> using ChucK and hadn't looked at source until I heard about this
> problem. Somehow it wasn't very easy for me to find information about
> how to check out the source from CVS, but I found it in the chuck-dev
> mailing list archive, eventually. Maybe it's time I subscribe there,
> The problem is that chuck_instr.h has this:
> #define uint unsigned long
> and sys/types.h has:
> #ifndef _POSIX_C_SOURCE
> typedef unsigned int uint; /* Sys V
> compatibility */
> which results in a:
> typedef unsigned int unsigned long;
> Fixing this is not the only hurdle, later on you'll see things like:
> /var/tmp//ccAPkhiP.s:20471:no such 386 instruction: `fctiw'
> /var/tmp//ccAPkhiP.s:20472:no such 386 instruction: `stfd'
> which is caused by inline assembly for the wrong architecure getting
> picked up from util_sndfile.h (looks like OS X does have lrint() and
> lrintf() so there should be no need for asm at all).
> An Intel Mac shouldn't be necessary to debug these kinds of issues.
> All you need is recent developer tools with universal libraries and
> you'll be able to specify "-arch i386" in compiler and linker flags
> to produce Intel binaries on a PPC machine.
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users