[PD-dev] devel_0_38 probs on osx 10.4.1
Thomas Grill
gr at grrrr.org
Tue Jun 28 17:35:49 CEST 2005
Hi Jamie,
>
> On Jun 28, 2005, at 4:03 AM, Thomas Grill wrote:
>> I checked in a few changes to the asm functions for PPC... they
>> compile now, but i can't really say whether they work as they
>> should...
>
> ...is there a reason why they have to be in assembly, or could we have
> a "pure c" fallback? I admit I don't have any idea what this is
> supposed to do, but then I haven't looked at it much: is there a good
> document that says what all of these "extra" flags actually do?
i think TIm should elaborate on this....
concerning the assembly: if one wants lock-free fifos (yes, we want
them!!) there's no other way to do it, except the OS has these
functions which i don't know about.
>
>> I found some more problems:
>>
>> - surprisingly UNISTD wasn't defined for OSX, this is fixed now
>> (although UNISTD should probably be dependent on HAVE_UNISTD in the
>> configure script)
>>
>> - still portaudio and portmidi is not found, because the paths to
>> these packages are not included by the configure script. It goes
>> beyond my knowledge (and interests) to make this work in a clean way,
>> so maybe someone else could jump in here?!
>
> ...is this a problem on other platforms? I suppose not, or it'd be
> fixed...anyway, is devel_0_38 based on portaudio v18 or the newer v19
> (both seem to be in the cvs)?
>
i think Tim is working on that right now... he's sitting in my working
room about 3 meters away...
> ...I also notice that there's a -DMACOSX: this should probably be
> removed and the #ifdef's changed to __APPLE__, which is a "built-in"
> preprocessor define...unless, of course, the define is something to do
> with endianness, in which case we need to switch it to __BIG_ENDIAN__
> or __LITTLE_ENDIAN__...
>
you're probably right... MACOSX and __APPLE__ should be exchangable
best,
Thomas
More information about the Pd-dev
mailing list