[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