...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?
well, i've introduced them for a thread-safe stack handling ... basically, you can't do that with plain c...
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)
i'm fixing this at the moment ...
- 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?!
working on this, too
...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 should compile, but i'd suggest to use v19 ...
...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__...
this is basically a good idea ...
cheers ... tim