hey,
...thought I'd start using this devel version, but can't compile it using gcc 4.0 on osx 10.4.1...I've heard about a scons version of the build system, but know even less about that than configure/make, so I went that route...
...right off the bat, I couldn't do "./bootstrap.sh", because I have newer versions of some of the called programs (both aclocal and automake are 1.9.5 here): perhaps we should just change the script to "aclocal" and "automake", rather than expect specific versions?
...anyway, here's what I used to configure, based on some email suggestion of tim's:
./configure --enable-lockfree --enable-newhash --enable-jack --enable- fftw --enable-simd --enable-optimize=G4 --enable-atomic --enable- debug --prefix=/Users/tigital/devel_0_38 --libdir=/Users/tigital/dev/ libs --enable-fftw
...sidenote: is this the correct way to tell configure where my fftw3f is? I have it in a non-standard place...
...and here's where the compile dies:
if gcc -DPACKAGE_NAME="PureData" -DPACKAGE_TARNAME="pd" - DPACKAGE_VERSION="0.38-4-devel-2" -DPACKAGE_STRING="PureData\ 0.38-4-devel-2" -DPACKAGE_BUGREPORT="pd-list@iem.at" -DPACKAGE="pd " -DVERSION="0.38-4-devel-2" -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 - DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 - DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 - DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 - DTIME_WITH_SYS_TIME=1 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 - DHAVE_LIMITS_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 - DHAVE_UNISTD_H=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 - DHAVE_GETTIMEOFDAY=1 -DHAVE_SELECT=1 -DHAVE_SOCKET=1 - DHAVE_STRERROR=1 -DDL_OPEN=1 -DHAVE_LIBM=1 -DHAVE_LIBPTHREAD=1 - DHAVE_LIBX11=1 -DHAVE_LIBTK8_4=1 -DUSEAPI_JACK=1 -DUSEAPI_ALSA=1 - DATOMIC=1 -DNEWHASH=1 -DLOCKFREE=1 -DUSEAPI_PORTAUDIO=1 - DPA_BIG_ENDIAN=1 -DMACOSX=1 -I. -I. -DINSTALL_PREFIX="/Users/ tigital/devel_0_38" -fno-strict-aliasing -g -DJACK_XRUN -O2 -MT pd- m_obj.o -MD -MP -MF ".deps/pd-m_obj.Tpo" -c -o pd-m_obj.o `test -f 'm_obj.c' || echo './'`m_obj.c; \ then mv -f ".deps/pd-m_obj.Tpo" ".deps/pd-m_obj.Po"; else rm -f ".deps/pd-m_obj.Tpo"; exit 1; fi m_obj.c: In function 'outlet_bang': m_obj.c:384: error: redeclaration of 'scp_i' with no linkage m_obj.c:373: error: previous declaration of 'scp_i' was here m_obj.c:384: error: 'i' undeclared (first use in this function) m_obj.c:384: error: (Each undeclared identifier is reported only once m_obj.c:384: error: for each function it appears in.) m_obj.c:384: error: 'scp_' undeclared (first use in this function) m_obj.c:384: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_pointer': m_obj.c:414: error: redeclaration of 'scp_i' with no linkage m_obj.c:393: error: previous declaration of 'scp_i' was here m_obj.c:414: error: 'i' undeclared (first use in this function) m_obj.c:414: error: 'scp_' undeclared (first use in this function) m_obj.c:414: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_float': m_obj.c:433: error: redeclaration of 'scp_i' with no linkage m_obj.c:422: error: previous declaration of 'scp_i' was here m_obj.c:433: error: 'i' undeclared (first use in this function) m_obj.c:433: error: 'scp_' undeclared (first use in this function) m_obj.c:433: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_symbol': m_obj.c:452: error: redeclaration of 'scp_i' with no linkage m_obj.c:441: error: previous declaration of 'scp_i' was here m_obj.c:452: error: 'i' undeclared (first use in this function) m_obj.c:452: error: 'scp_' undeclared (first use in this function) m_obj.c:452: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_list': m_obj.c:471: error: redeclaration of 'scp_i' with no linkage m_obj.c:460: error: previous declaration of 'scp_i' was here m_obj.c:471: error: 'i' undeclared (first use in this function) m_obj.c:471: error: 'scp_' undeclared (first use in this function) m_obj.c:471: error: invalid lvalue in asm output 0 m_obj.c: In function 'outlet_anything': m_obj.c:490: error: redeclaration of 'scp_i' with no linkage m_obj.c:479: error: previous declaration of 'scp_i' was here m_obj.c:490: error: 'i' undeclared (first use in this function) m_obj.c:490: error: 'scp_' undeclared (first use in this function) m_obj.c:490: error: invalid lvalue in asm output 0 make[1]: *** [pd-m_obj.o] Error 1 make: *** [all-recursive] Error 1
...so, I've looked at the source here, but I don't understand the macro's being used...
l8r, jamie
Hi all,
...right off the bat, I couldn't do "./bootstrap.sh", because I have newer versions of some of the called programs (both aclocal and automake are 1.9.5 here): perhaps we should just change the script to "aclocal" and "automake", rather than expect specific versions?
Yes, that would be a good idea, i have also had problems with this....
...and here's where the compile dies:
if gcc -DPACKAGE_NAME="PureData" -DPACKAGE_TARNAME="pd" -DPACKAGE_VERSION="0.38-4-devel-2" -DPACKAGE_STRING="PureData\ 0.38-4-devel-2" -DPACKAGE_BUGREPORT="pd-list@iem.at" -DPACKAGE="pd" -DVERSION="0.38-4-devel-2" -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DTIME_WITH_SYS_TIME=1 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_SELECT=1 -DHAVE_SOCKET=1 -DHAVE_STRERROR=1 -DDL_OPEN=1 -DHAVE_LIBM=1 -DHAVE_LIBPTHREAD=1 -DHAVE_LIBX11=1 -DHAVE_LIBTK8_4=1 -DUSEAPI_JACK=1 -DUSEAPI_ALSA=1 -DATOMIC=1 -DNEWHASH=1 -DLOCKFREE=1 -DUSEAPI_PORTAUDIO=1 -DPA_BIG_ENDIAN=1 -DMACOSX=1 -I. -I. -DINSTALL_PREFIX="/Users/tigital/devel_0_38" -fno-strict-aliasing -g -DJACK_XRUN -O2 -MT pd-m_obj.o -MD -MP -MF ".deps/pd-m_obj.Tpo" -c -o pd-m_obj.o `test -f 'm_obj.c' || echo './'`m_obj.c; \ then mv -f ".deps/pd-m_obj.Tpo" ".deps/pd-m_obj.Po"; else rm -f ".deps/pd-m_obj.Tpo"; exit 1; fi m_obj.c: In function 'outlet_bang': m_obj.c:384: error: redeclaration of 'scp_i' with no linkage
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...
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?!
best greetings, Thomas
hi thomas,
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 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 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__...
thanx, jamie
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
...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
On Jun 28, 2005, at 4:03 AM, Thomas Grill wrote:
Hi all,
...right off the bat, I couldn't do "./bootstrap.sh", because I have newer versions of some of the called programs (both aclocal and automake are 1.9.5 here): perhaps we should just change the script to "aclocal" and "automake", rather than expect specific versions?
Yes, that would be a good idea, i have also had problems with this....
There should then be a README that clearly states which versions of the autotools are needed. They vary greatly. Usually, it seems that it is easiest for all involved if everyone uses specific versions.
.hc
...and here's where the compile dies:
if gcc -DPACKAGE_NAME="PureData" -DPACKAGE_TARNAME="pd" -DPACKAGE_VERSION="0.38-4-devel-2" -DPACKAGE_STRING="PureData\ 0.38-4-devel-2" -DPACKAGE_BUGREPORT="pd-list@iem.at" -DPACKAGE="pd" -DVERSION="0.38-4-devel-2" -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DTIME_WITH_SYS_TIME=1 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_SELECT=1 -DHAVE_SOCKET=1 -DHAVE_STRERROR=1 -DDL_OPEN=1 -DHAVE_LIBM=1 -DHAVE_LIBPTHREAD=1 -DHAVE_LIBX11=1 -DHAVE_LIBTK8_4=1 -DUSEAPI_JACK=1 -DUSEAPI_ALSA=1 -DATOMIC=1 -DNEWHASH=1 -DLOCKFREE=1 -DUSEAPI_PORTAUDIO=1 -DPA_BIG_ENDIAN=1 -DMACOSX=1 -I. -I. -DINSTALL_PREFIX="/Users/tigital/devel_0_38" -fno-strict-aliasing -g -DJACK_XRUN -O2 -MT pd-m_obj.o -MD -MP -MF ".deps/pd-m_obj.Tpo" -c -o pd-m_obj.o `test -f 'm_obj.c' || echo './'`m_obj.c; \ then mv -f ".deps/pd-m_obj.Tpo" ".deps/pd-m_obj.Po"; else rm -f ".deps/pd-m_obj.Tpo"; exit 1; fi m_obj.c: In function 'outlet_bang': m_obj.c:384: error: redeclaration of 'scp_i' with no linkage
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...
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?!
best greetings, Thomas
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
There should then be a README that clearly states which versions of the autotools are needed. They vary greatly. Usually, it seems that it is easiest for all involved if everyone uses specific versions.
as soon as i have the scons build system working on osx, i'll change the readme file ...
cheers ... tim
On Jun 29, 2005, at 11:59 AM, Tim Blechmann wrote:
There should then be a README that clearly states which versions of the autotools are needed. They vary greatly. Usually, it seems that it is easiest for all involved if everyone uses specific versions.
as soon as i have the scons build system working on osx, i'll change the readme file ...
...maybe we should get the configure/make system working first? I just tried again and get a weird error in the configure process:
checking for fftwf_plan_dft_r2c_1d in -lfftw3f... no ./configure: line 6565: test: ==: unary operator expected configure: creating ./config.status
...this section of the configure file is the last line of the following:
if test `uname -s` == Darwin; then DARWIN_TRUE= DARWIN_FALSE='#' else DARWIN_TRUE='#' DARWIN_FALSE= fi
if test `uname -s` == Darwin; then case $LIBOBJS in "s_midi_pm.$ac_objext" | \ *" s_midi_pm.$ac_objext" | \ "s_midi_pm.$ac_objext "* | \ *" s_midi_pm.$ac_objext "* ) ;; *) LIBOBJS="$LIBOBJS s_midi_pm.$ac_objext" ;; esac
case $LIBOBJS in "s_audio_pa.$ac_objext" | \ *" s_audio_pa.$ac_objext" | \ "s_audio_pa.$ac_objext "* | \ *" s_audio_pa.$ac_objext "* ) ;; *) LIBOBJS="$LIBOBJS s_audio_pa.$ac_objext" ;; esac
cat >>confdefs.h <<_ACEOF #define USEAPI_PORTAUDIO 1 _ACEOF
cat >>confdefs.h <<_ACEOF #define PA_BIG_ENDIAN 1 _ACEOF
cat >>confdefs.h <<_ACEOF #define MACOSX 1 _ACEOF
cat >>confdefs.h <<_ACEOF #define UNISTD 1 _ACEOF
...obviously I haven't figured out where the spurious '==' is: maybe in _ACEOF macro? Also, with an eye toward the future, darwin will not always signify "#define PA_BIG_ENDIAN 1" ;-)
thanx, jamie
...maybe we should get the configure/make system working first? I just tried again and get a weird error in the configure process:
well, i'm currently adapting the scons script for osx ... basically to abandon the autobuild tools ... they suck!
in _ACEOF macro? Also, with an eye toward the future, darwin will not always signify "#define PA_BIG_ENDIAN 1" ;-)
i'd prefer to build portaudio as a shared library ... i think it's cleaner than just compiling the portaudio sources into the pd binary / pd library... so i suggest the portaudio guys should take care of that...
cheers ... tim