...like the subject says, I'm wondering which branch we are using with pd's cvs HEAD: I assume that it's either "HEAD" or "v19-devel"...
...I ask because I was trying to compile it (and devel), and both die on osx when we try to compile portaudio/portmidi-oriented files...I was able to get around this by finding and inserting the missing files from a downloaded snapshot of portaudio v19-devel, but before I commit these missing files to cvs, I want to make sure we're on the same page...
l8r, jamie
...I ask because I was trying to compile it (and devel), and both die on osx when we try to compile portaudio/portmidi-oriented files...I was able to get around this by finding and inserting the missing files from a downloaded snapshot of portaudio v19-devel, but before I commit these missing files to cvs, I want to make sure we're on the same page...
i'm working on it at the moment ... devel is using v19 ... can you update your cvs to check, if it's working? i could compile devel_0_39 with scons on my gentoo machine and thomas grill's minimac ... (couldn't test the mac build, though)
cheers ... tim
On Jul 12, 2005, at 12:14 PM, Tim Blechmann wrote:
i'm working on it at the moment ... devel is using v19 ... can you update your cvs to check, if it's working? i could compile devel_0_39 with scons on my gentoo machine and thomas grill's minimac ... (couldn't test the mac build, though)
hi tim,
...just updated and ran scons, and things seem to be improving, but we have a problem here:
gcc -O3 -fprefetch-loop-arrays -DNEWHASH -DLOCKFREE -DUNISTD - DPA_BIG_ENDIAN -DPA_USE_COREAUDIO -DMACOSX -DUSEAPI_PORTAUDIO -DPA19 - I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/ Tcl.framework/Headers -Isrc -Iportmidi_osx -Iportaudio/pa_common - Iportaudio/pablio -c -o src/s_midi_pm.o src/s_midi_pm.c src/s_midi_pm.c: In function 'sys_do_open_midi': src/s_midi_pm.c:51: error: too few arguments to function 'Pm_OpenInput' scons: *** [src/s_midi_pm.o] Error 1 scons: building terminated because of errors.
I'll look into it, maybe something just didn't get updated?
jamie
...just updated and ran scons, and things seem to be improving, but we have a problem here:
just for the archive ... fixed in cvs ...
cheers ... tim
On Jul 12, 2005, at 1:52 PM, Tim Blechmann wrote:
...just updated and ran scons, and things seem to be improving, but we have a problem here:
just for the archive ... fixed in cvs ...
...fixed, but just to the next bug :-\ Luckily I know a bit more about it:
/usr/bin/ld: Undefined symbols: _simd_runtime_check _copyvec_simd _testcopyvec_simd _zerovec_simd _setvec_simd _copyvec_simd_unalignedsrc _testaddvec_simd _sched_setscheduler collect2: ld returned 1 exit status
...at first this didn't make much sense, but then I noticed src/ m_simd_ve_gcc.c used __ALTIVEC__ in an ifdef, but nowhere was - maltivec to be found! None of the simd stuff was being comipled, so I added this to src/SConscript:
if not pdenv['nosimd']: if pdenv['PLATFORM'] != 'darwin': flags += " -mfpmath=sse -mmmx -msse -msse2" else: flags += " -maltivec"
...but now we've got all kinds of altivec probs (at least on 10.4.1)...I'll keep poking away! BTW, this'll have to be changed to a __BIGENDIAN__ instead of darwin check when the mactels actually appear...
jamie
...at first this didn't make much sense, but then I noticed src/ m_simd_ve_gcc.c used __ALTIVEC__ in an ifdef, but nowhere was - maltivec to be found! None of the simd stuff was being comipled, so I added this to src/SConscript:
thanks for fixing ...
...but now we've got all kinds of altivec probs (at least on
what kind of?
10.4.1)...I'll keep poking away! BTW, this'll have to be changed to a __BIGENDIAN__ instead of darwin check when the mactels actually appear...
right ... but we'll have to change some code, then ...
cheers ... tim
On Jul 12, 2005, at 3:24 PM, Tim Blechmann wrote:
...but now we've got all kinds of altivec probs (at least on
what kind of?
gcc -O3 -fprefetch-loop-arrays -maltivec -DNEWHASH -DLOCKFREE - DUNISTD -DPA_BIG_ENDIAN -DPA_USE_COREAUDIO -DMACOSX - DUSEAPI_PORTAUDIO -DPA19 -I/Library/Frameworks/Tk.framework/Headers - I/Library/Frameworks/Tcl.framework/Headers -Isrc -Iportmidi_osx - Iportaudio/pa_common -Iportaudio/pablio -c -o src/m_simd_ve_gcc.o src/ m_simd_ve_gcc.c src/m_simd_ve_gcc.c: In function 'LoadUnaligned': src/m_simd_ve_gcc.c:29: error: incompatible types in return src/m_simd_ve_gcc.c: In function 'zerovec_simd': src/m_simd_ve_gcc.c:45: error: AltiVec argument passed to unprototyped function src/m_simd_ve_gcc.c:46: error: AltiVec argument passed to unprototyped function src/m_simd_ve_gcc.c:47: error: AltiVec argument passed to unprototyped function src/m_simd_ve_gcc.c:48: error: AltiVec argument passed to unprototyped function src/m_simd_ve_gcc.c: In function 'setvec_simd': src/m_simd_ve_gcc.c:56: error: AltiVec argument passed to unprototyped function src/m_simd_ve_gcc.c:57: error: AltiVec argument passed to unprototyped function src/m_simd_ve_gcc.c:58: error: AltiVec argument passed to unprototyped function src/m_simd_ve_gcc.c:59: error: AltiVec argument passed to unprototyped function src/m_simd_ve_gcc.c: In function 'copyvec_simd': src/m_simd_ve_gcc.c:66: error: incompatible types in initialization
...and so on for some time (all the way to line 736!)...this seems to be telling us something, but not sure atm...
jamie
On Jul 12, 2005, at 4:00 PM, james tittle wrote:
On Jul 12, 2005, at 3:24 PM, Tim Blechmann wrote:
...but now we've got all kinds of altivec probs (at least on
what kind of?
gcc -O3 -fprefetch-loop-arrays -maltivec -DNEWHASH -DLOCKFREE - DUNISTD -DPA_BIG_ENDIAN -DPA_USE_COREAUDIO -DMACOSX - DUSEAPI_PORTAUDIO -DPA19 -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tcl.framework/Headers -Isrc -Iportmidi_osx - Iportaudio/pa_common -Iportaudio/pablio -c -o src/m_simd_ve_gcc.o src/m_simd_ve_gcc.c
...now they've gone away if I use "-faltivec" instead of "- maltivec": not sure what the difference is...however, it does lead to a new warning:
gcc -O3 -fprefetch-loop-arrays -faltivec -fPIC -DNEWHASH -DLOCKFREE - DUNISTD -DPA_BIG_ENDIAN -DPA_USE_COREAUDIO -DMACOSX - DUSEAPI_PORTAUDIO -DPA19 -I/Library/Frameworks/Tk.framework/Headers - I/Library/Frameworks/Tcl.framework/Headers -Isrc -Iportmidi_osx - Iportaudio/pa_common -Iportaudio/pablio -c -o src/t_tkcmd.os src/ t_tkcmd.c src/t_tkcmd.c: In function 'pd_readsocket': src/t_tkcmd.c:119: warning: vectorised memset disabled due to use of - faltivec without -maltivec
...and...
gcc -O3 -fprefetch-loop-arrays -faltivec -DNEWHASH -DLOCKFREE - DUNISTD -DPA_BIG_ENDIAN -DPA_USE_COREAUDIO -DMACOSX - DUSEAPI_PORTAUDIO -DPA19 -I/Library/Frameworks/Tk.framework/Headers - I/Library/Frameworks/Tcl.framework/Headers -Isrc -Iportmidi_osx - Iportaudio/pa_common -Iportaudio/pablio -c -o src/s_inter.o src/ s_inter.c src/s_inter.c: In function 'sys_pollsockets': src/s_inter.c:167: warning: vectorised memset disabled due to use of - faltivec without -maltivec
...but now I just get one error:
/usr/bin/ld: Undefined symbols: _sched_setscheduler
...where's this?
jamie
...now they've gone away if I use "-faltivec" instead of "- maltivec": not sure what the difference is...however, it does lead to a new warning:
well, i'd suggest to use both -faltivec and -maltivec ...
/usr/bin/ld: Undefined symbols: _sched_setscheduler
this is defined it m_sched.c, line 866 ... i'll check if it has been commited successfully ...
cheers ... tim
On Jul 12, 2005, at 4:37 PM, Tim Blechmann wrote:
...now they've gone away if I use "-faltivec" instead of "- maltivec": not sure what the difference is...however, it does lead to a new warning:
well, i'd suggest to use both -faltivec and -maltivec ...
...yep, their combined superpowers work wonders on the warnings :-)
/usr/bin/ld: Undefined symbols: _sched_setscheduler
this is defined it m_sched.c, line 866 ... i'll check if it has been commited successfully ...
...line 866 for my m_sched.c is sys_setscheduler(), not sched_setscheduler()...I'm beginning to think this may be due to some apple shenanigans with switching around posix defines and such...?
jamie
...line 866 for my m_sched.c is sys_setscheduler(), not sched_setscheduler()...I'm beginning to think this may be due to some apple shenanigans with switching around posix defines and such...?
it seems that sys_setscheduler() is not implemented in osx / bsd ...
but violating the POSIX standard, _POSIX_PRIORITY_SCHEDULING is defined ... quoting Linux Programmer's Manual, SETSCHEDULER(2):
POSIX systems on which sched_setscheduler and sched_getscheduler are available define _POSIX_PRIORITY_SCHEDULING in <unistd.h>.
seems, we'll have to find another way to set the realtime scheduling on osx btw, you're running tiger / gcc 4.0, aren't you? it compiled fine on panther with gcc 3.3 ... hopefully osx 10.5 (yet another cat) will finally be posix compliant ...
until then, we'll probably have to write a workaround with getpriority and setpriority ...
cheers ... tim
-
james tittle -
Tim Blechmann