Oops, I accidentally just sent my last post to Hans. Please read this and the post below...
I have been slowly figuring out the last problem, where gcc can't find my headers in /usr/include. It is because the configure line:
if test "x$fat" == "xyes";
then
MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"
First, I don't know why this is necessary, but I'm sure somebody does. I also don't know why OS X 10.6 is being detected as fat anything.
I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't find a good stdarg.h, as the one include within that sdk has a #include_next stdarg.h directive. Then, with this -sysroot flag, gcc doesn't search any other directory and none of the 20 other stdarg.h files on my computer are found. I remove this flag and the header files are found elsewhere just fine.
I compiled Portaudio from svn as universal binary with 64bit. But, this library doesn't work with Pd's portaudio source files and the new sources don't work with Pd's sources. So, I can't get past building the portaudio objects. I tried just using jack with "./configure --enable-jack --disable-portaudio", but the build script still tries to build portaudio and fails.
This is all with pd vanilla from Miller's website. I'm also trying to build the Pd extended sources, but I suppose I should start a new thread for the problem I hit there..
On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote:
Macports made me a universal binary portaudio, thankfully because I could not get it to compile as 64 bit from the source (I posted why on the portaudio mailing list).
I'm having other annoying problems with my build system, probably something very stupid that I am not aware of. Neither Pd nor Pd-extended can find header files in /usr/include. This isn't so hard to include as a CFLAGS flag, but then it still can't find stdarg.h, which just makes me think my build system is broken.
I'm working through the various errors to getting Pd-extended building on Snow Leopard as 64 bit, but I have to say I'm probably not the best candidate as this is the first mac that I've had in years. Truthfully, I was looking forward to a time when things 'just worked' :) Not there yet.
Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner hans@at.or.atwrote:
It seems that portaudio should build as 64-bit, perhaps its worth trying to upgrade the portaudio files that are included in Pd-extended. I recently updated the pd-extended/0.42.5 branch to the most recent stable portaudio.
http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd-core right now. This will support the iPhone, but should also work on Mac OS X. With this, it should be possible to get working audio on Mac OS X without portaudio.
AFAIK, Fink does support 64-bit now, so as long as the libs support it, then Fink should work. I'd say it would be worthwhile building Pd-extended 64-bit without the Fink/Macports dependencies, since most included externals don't need any other libs.
.hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner hans@at.or.atwrote:
You need to set the LDFLAGS to -arch i386 also. Or even better, try doing a 64-bit Snow Leopard build of Pd-extended.
I'd love to try that, but I'm still working to get a 64-bit Snow Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is limited as far as I can see, so I'm having to compile each piece from source.
cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with
Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because Pd-extended is i386 and my externals are compiling as x86_64.
All I can find on this is to force the build to i386 with the gcc flag '-arch i386', but the linker won't allow it:
ld: warning: in incr.o, file is not of required architecture
and then, I again have the 64 bit version: $ file incr.pd_darwin incr.pd_darwin: Mach-O 64-bit bundle x86_64
Anyone know how to get these guys to work with Pd-extended?
Rich _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
The build system in vanilla/extended is pretty ugly, especially for
Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been
rewritten from scratch to be a full autotools build system. That
should fix the -isysroot and --disable-portaudio problem you mention.
Try it out, and we can fix any issues there.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read
this and the post below...I have been slowly figuring out the last problem, where gcc can't
find my headers in /usr/include. It is because the configure line:if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody
does. I also don't know why OS X 10.6 is being detected as fat
anything.I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc
can't find a good stdarg.h, as the one include within that sdk has a
#include_next stdarg.h directive. Then, with this -sysroot flag,
gcc doesn't search any other directory and none of the 20 other
stdarg.h files on my computer are found. I remove this flag and the
header files are found elsewhere just fine.I compiled Portaudio from svn as universal binary with 64bit. But,
this library doesn't work with Pd's portaudio source files and the
new sources don't work with Pd's sources. So, I can't get past
building the portaudio objects. I tried just using jack with "./ configure --enable-jack --disable-portaudio", but the build script
still tries to build portaudio and fails.This is all with pd vanilla from Miller's website. I'm also trying
to build the Pd extended sources, but I suppose I should start a new
thread for the problem I hit there..On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote: Macports made me a universal binary portaudio, thankfully because I
could not get it to compile as 64 bit from the source (I posted why
on the portaudio mailing list).I'm having other annoying problems with my build system, probably
something very stupid that I am not aware of. Neither Pd nor Pd- extended can find header files in /usr/include. This isn't so hard
to include as a CFLAGS flag, but then it still can't find stdarg.h,
which just makes me think my build system is broken.I'm working through the various errors to getting Pd-extended
building on Snow Leopard as 64 bit, but I have to say I'm probably
not the best candidate as this is the first mac that I've had in
years. Truthfully, I was looking forward to a time when things
'just worked' :) Not there yet.Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner
hans@at.or.at wrote:It seems that portaudio should build as 64-bit, perhaps its worth
trying to upgrade the portaudio files that are included in Pd- extended. I recently updated the pd-extended/0.42.5 branch to the
most recent stable portaudio.http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd- core right now. This will support the iPhone, but should also work
on Mac OS X. With this, it should be possible to get working audio
on Mac OS X without portaudio.AFAIK, Fink does support 64-bit now, so as long as the libs support
it, then Fink should work. I'd say it would be worthwhile building
Pd-extended 64-bit without the Fink/Macports dependencies, since
most included externals don't need any other libs..hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
You need to set the LDFLAGS to -arch i386 also. Or even better,
try doing a 64-bit Snow Leopard build of Pd-extended.I'd love to try that, but I'm still working to get a 64-bit Snow
Leopard build of Pd-vanilla. Portaudio won't let me do it yet.
Macports is limited as far as I can see, so I'm having to compile
each piece from source.cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with Pd- extended... in OS X Snow Leopard. So far it hasn't been easy
because Pd-extended is i386 and my externals are compiling as
x86_64.All I can find on this is to force the build to i386 with the gcc
flag '-arch i386', but the linker won't allow it:ld: warning: in incr.o, file is not of required architecture
and then, I again have the 64 bit version: $ file incr.pd_darwin incr.pd_darwin: Mach-O 64-bit bundle x86_64
Anyone know how to get these guys to work with Pd-extended?
Rich _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country."
Nobody gives their life for anything. We steal the lives of these
kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris
McCormick
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On running a regular ./configure in the gui rewrite branch, I get the error:
checking for C compiler default output file name...
configure: error: in
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.
I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner hans@at.or.atwrote:
The build system in vanilla/extended is pretty ugly, especially for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been rewritten from scratch to be a full autotools build system. That should fix the -isysroot and --disable-portaudio problem you mention. Try it out, and we can fix any issues there.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read this and the post below...
I have been slowly figuring out the last problem, where gcc can't find my headers in /usr/include. It is because the configure line:
if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody does. I also don't know why OS X 10.6 is being detected as fat anything.
I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't find a good stdarg.h, as the one include within that sdk has a #include_next stdarg.h directive. Then, with this -sysroot flag, gcc doesn't search any other directory and none of the 20 other stdarg.h files on my computer are found. I remove this flag and the header files are found elsewhere just fine.
I compiled Portaudio from svn as universal binary with 64bit. But, this library doesn't work with Pd's portaudio source files and the new sources don't work with Pd's sources. So, I can't get past building the portaudio objects. I tried just using jack with "./configure --enable-jack --disable-portaudio", but the build script still tries to build portaudio and fails.
This is all with pd vanilla from Miller's website. I'm also trying to build the Pd extended sources, but I suppose I should start a new thread for the problem I hit there..
On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote:
Macports made me a universal binary portaudio, thankfully because I could not get it to compile as 64 bit from the source (I posted why on the portaudio mailing list).
I'm having other annoying problems with my build system, probably something very stupid that I am not aware of. Neither Pd nor Pd-extended can find header files in /usr/include. This isn't so hard to include as a CFLAGS flag, but then it still can't find stdarg.h, which just makes me think my build system is broken.
I'm working through the various errors to getting Pd-extended building on Snow Leopard as 64 bit, but I have to say I'm probably not the best candidate as this is the first mac that I've had in years. Truthfully, I was looking forward to a time when things 'just worked' :) Not there yet.
Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner hans@at.or.atwrote:
It seems that portaudio should build as 64-bit, perhaps its worth trying to upgrade the portaudio files that are included in Pd-extended. I recently updated the pd-extended/0.42.5 branch to the most recent stable portaudio.
http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd-core right now. This will support the iPhone, but should also work on Mac OS X. With this, it should be possible to get working audio on Mac OS X without portaudio.
AFAIK, Fink does support 64-bit now, so as long as the libs support it, then Fink should work. I'd say it would be worthwhile building Pd-extended 64-bit without the Fink/Macports dependencies, since most included externals don't need any other libs.
.hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner hans@at.or.atwrote:
You need to set the LDFLAGS to -arch i386 also. Or even better, try doing a 64-bit Snow Leopard build of Pd-extended.
I'd love to try that, but I'm still working to get a 64-bit Snow Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is limited as far as I can see, so I'm having to compile each piece from source.
cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with
Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because Pd-extended is i386 and my externals are compiling as x86_64.
All I can find on this is to force the build to i386 with the gcc flag '-arch i386', but the linker won't allow it:
ld: warning: in incr.o, file is not of required architecture
and then, I again have the 64 bit version: $ file incr.pd_darwin incr.pd_darwin: Mach-O 64-bit bundle x86_64
Anyone know how to get these guys to work with Pd-extended?
Rich _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Oops, my fault. I had some residual CFLAGS from trying to get Gem to compile... onward :)
On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote:
On running a regular ./configure in the gui rewrite branch, I get the error:
checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner hans@at.or.atwrote:
The build system in vanilla/extended is pretty ugly, especially for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been rewritten from scratch to be a full autotools build system. That should fix the -isysroot and --disable-portaudio problem you mention. Try it out, and we can fix any issues there.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read this and the post below...
I have been slowly figuring out the last problem, where gcc can't find my headers in /usr/include. It is because the configure line:
if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody does. I also don't know why OS X 10.6 is being detected as fat anything.
I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't find a good stdarg.h, as the one include within that sdk has a #include_next stdarg.h directive. Then, with this -sysroot flag, gcc doesn't search any other directory and none of the 20 other stdarg.h files on my computer are found. I remove this flag and the header files are found elsewhere just fine.
I compiled Portaudio from svn as universal binary with 64bit. But, this library doesn't work with Pd's portaudio source files and the new sources don't work with Pd's sources. So, I can't get past building the portaudio objects. I tried just using jack with "./configure --enable-jack --disable-portaudio", but the build script still tries to build portaudio and fails.
This is all with pd vanilla from Miller's website. I'm also trying to build the Pd extended sources, but I suppose I should start a new thread for the problem I hit there..
On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote:
Macports made me a universal binary portaudio, thankfully because I could not get it to compile as 64 bit from the source (I posted why on the portaudio mailing list).
I'm having other annoying problems with my build system, probably something very stupid that I am not aware of. Neither Pd nor Pd-extended can find header files in /usr/include. This isn't so hard to include as a CFLAGS flag, but then it still can't find stdarg.h, which just makes me think my build system is broken.
I'm working through the various errors to getting Pd-extended building on Snow Leopard as 64 bit, but I have to say I'm probably not the best candidate as this is the first mac that I've had in years. Truthfully, I was looking forward to a time when things 'just worked' :) Not there yet.
Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner hans@at.or.atwrote:
It seems that portaudio should build as 64-bit, perhaps its worth trying to upgrade the portaudio files that are included in Pd-extended. I recently updated the pd-extended/0.42.5 branch to the most recent stable portaudio.
http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd-core right now. This will support the iPhone, but should also work on Mac OS X. With this, it should be possible to get working audio on Mac OS X without portaudio.
AFAIK, Fink does support 64-bit now, so as long as the libs support it, then Fink should work. I'd say it would be worthwhile building Pd-extended 64-bit without the Fink/Macports dependencies, since most included externals don't need any other libs.
.hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner hans@at.or.atwrote:
You need to set the LDFLAGS to -arch i386 also. Or even better, try doing a 64-bit Snow Leopard build of Pd-extended.
I'd love to try that, but I'm still working to get a 64-bit Snow Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is limited as far as I can see, so I'm having to compile each piece from source.
cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with
Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because Pd-extended is i386 and my externals are compiling as x86_64.
All I can find on this is to force the build to i386 with the gcc flag '-arch i386', but the linker won't allow it:
ld: warning: in incr.o, file is not of required architecture
and then, I again have the 64 bit version: $ file incr.pd_darwin incr.pd_darwin: Mach-O 64-bit bundle x86_64
Anyone know how to get these guys to work with Pd-extended?
Rich _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Got it compiled and it looks nice. The portaudio failed, same as Pd-Vanilla, but I guess you aren't worried about that because you are working on getting coreaudio support (which would be nice). Jack works, everything is sounds nice and stable.
The only thing I noticed is that expr cannot be found. I have only tried a few of the example patches so far.
cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote:
Oops, my fault. I had some residual CFLAGS from trying to get Gem to compile... onward :)
On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote:
On running a regular ./configure in the gui rewrite branch, I get the error:
checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner hans@at.or.atwrote:
The build system in vanilla/extended is pretty ugly, especially for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been rewritten from scratch to be a full autotools build system. That should fix the -isysroot and --disable-portaudio problem you mention. Try it out, and we can fix any issues there.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read this and the post below...
I have been slowly figuring out the last problem, where gcc can't find my headers in /usr/include. It is because the configure line:
if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody does. I also don't know why OS X 10.6 is being detected as fat anything.
I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't find a good stdarg.h, as the one include within that sdk has a #include_next stdarg.h directive. Then, with this -sysroot flag, gcc doesn't search any other directory and none of the 20 other stdarg.h files on my computer are found. I remove this flag and the header files are found elsewhere just fine.
I compiled Portaudio from svn as universal binary with 64bit. But, this library doesn't work with Pd's portaudio source files and the new sources don't work with Pd's sources. So, I can't get past building the portaudio objects. I tried just using jack with "./configure --enable-jack --disable-portaudio", but the build script still tries to build portaudio and fails.
This is all with pd vanilla from Miller's website. I'm also trying to build the Pd extended sources, but I suppose I should start a new thread for the problem I hit there..
On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote:
Macports made me a universal binary portaudio, thankfully because I could not get it to compile as 64 bit from the source (I posted why on the portaudio mailing list).
I'm having other annoying problems with my build system, probably something very stupid that I am not aware of. Neither Pd nor Pd-extended can find header files in /usr/include. This isn't so hard to include as a CFLAGS flag, but then it still can't find stdarg.h, which just makes me think my build system is broken.
I'm working through the various errors to getting Pd-extended building on Snow Leopard as 64 bit, but I have to say I'm probably not the best candidate as this is the first mac that I've had in years. Truthfully, I was looking forward to a time when things 'just worked' :) Not there yet.
Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner hans@at.or.atwrote:
It seems that portaudio should build as 64-bit, perhaps its worth trying to upgrade the portaudio files that are included in Pd-extended. I recently updated the pd-extended/0.42.5 branch to the most recent stable portaudio.
http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd-core right now. This will support the iPhone, but should also work on Mac OS X. With this, it should be possible to get working audio on Mac OS X without portaudio.
AFAIK, Fink does support 64-bit now, so as long as the libs support it, then Fink should work. I'd say it would be worthwhile building Pd-extended 64-bit without the Fink/Macports dependencies, since most included externals don't need any other libs.
.hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner hans@at.or.atwrote:
You need to set the LDFLAGS to -arch i386 also. Or even better, try doing a 64-bit Snow Leopard build of Pd-extended.
I'd love to try that, but I'm still working to get a 64-bit Snow Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is limited as far as I can see, so I'm having to compile each piece from source.
cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with > Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because > Pd-extended is i386 and my externals are compiling as x86_64. > > All I can find on this is to force the build to i386 with the gcc > flag '-arch i386', but the linker won't allow it: > > ld: warning: in incr.o, file is not of required architecture > > and then, I again have the 64 bit version: > $ file incr.pd_darwin > incr.pd_darwin: Mach-O 64-bit bundle x86_64 > > Anyone know how to get these guys to work with Pd-extended? > > Rich > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
portaudio provides CoreAudio support already. It is AudioUnit support
that is in the works, which I suppose is part of CoreAudio. What are
the errors with portaudio in pd-gui-rewrite? It would be good to get
those fixed there, since you said that portaudio on its own can build
fine for 64-bit (or am I mistaken?)
.hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as Pd- Vanilla, but I guess you aren't worried about that because you are
working on getting coreaudio support (which would be nice). Jack
works, everything is sounds nice and stable.The only thing I noticed is that expr cannot be found. I have only
tried a few of the example patches so far.cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote: Oops, my fault. I had some residual CFLAGS from trying to get Gem
to compile... onward :)On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote: On running a regular ./configure in the gui rewrite branch, I get
the error:checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui- rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
The build system in vanilla/extended is pretty ugly, especially for
Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has
been rewritten from scratch to be a full autotools build system.
That should fix the -isysroot and --disable-portaudio problem you
mention. Try it out, and we can fix any issues there.svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read
this and the post below...I have been slowly figuring out the last problem, where gcc can't
find my headers in /usr/include. It is because the configure line:if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody
does. I also don't know why OS X 10.6 is being detected as fat
anything.I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc
can't find a good stdarg.h, as the one include within that sdk has
a #include_next stdarg.h directive. Then, with this -sysroot flag,
gcc doesn't search any other directory and none of the 20 other
stdarg.h files on my computer are found. I remove this flag and
the header files are found elsewhere just fine.I compiled Portaudio from svn as universal binary with 64bit. But,
this library doesn't work with Pd's portaudio source files and the
new sources don't work with Pd's sources. So, I can't get past
building the portaudio objects. I tried just using jack with "./ configure --enable-jack --disable-portaudio", but the build script
still tries to build portaudio and fails.This is all with pd vanilla from Miller's website. I'm also trying
to build the Pd extended sources, but I suppose I should start a
new thread for the problem I hit there..On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote: Macports made me a universal binary portaudio, thankfully because I
could not get it to compile as 64 bit from the source (I posted why
on the portaudio mailing list).I'm having other annoying problems with my build system, probably
something very stupid that I am not aware of. Neither Pd nor Pd- extended can find header files in /usr/include. This isn't so hard
to include as a CFLAGS flag, but then it still can't find stdarg.h,
which just makes me think my build system is broken.I'm working through the various errors to getting Pd-extended
building on Snow Leopard as 64 bit, but I have to say I'm probably
not the best candidate as this is the first mac that I've had in
years. Truthfully, I was looking forward to a time when things
'just worked' :) Not there yet.Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
It seems that portaudio should build as 64-bit, perhaps its worth
trying to upgrade the portaudio files that are included in Pd- extended. I recently updated the pd-extended/0.42.5 branch to the
most recent stable portaudio.http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd- core right now. This will support the iPhone, but should also
work on Mac OS X. With this, it should be possible to get working
audio on Mac OS X without portaudio.AFAIK, Fink does support 64-bit now, so as long as the libs
support it, then Fink should work. I'd say it would be worthwhile
building Pd-extended 64-bit without the Fink/Macports
dependencies, since most included externals don't need any other
libs..hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
You need to set the LDFLAGS to -arch i386 also. Or even better,
try doing a 64-bit Snow Leopard build of Pd-extended.I'd love to try that, but I'm still working to get a 64-bit Snow
Leopard build of Pd-vanilla. Portaudio won't let me do it yet.
Macports is limited as far as I can see, so I'm having to compile
each piece from source.cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with Pd- extended... in OS X Snow Leopard. So far it hasn't been easy
because Pd-extended is i386 and my externals are compiling as
x86_64.All I can find on this is to force the build to i386 with the gcc
flag '-arch i386', but the linker won't allow it:ld: warning: in incr.o, file is not of required architecture
and then, I again have the 64 bit version: $ file incr.pd_darwin incr.pd_darwin: Mach-O 64-bit bundle x86_64
Anyone know how to get these guys to work with Pd-extended?
Rich _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country."
Nobody gives their life for anything. We steal the lives of
these kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." -
Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
http://at.or.at/hans/
I compiled the pd-gui-rewrite branch today as 64bit with portaudio support, but haven't tested it much.
To compile portaudio as 64bit, you need the the sources from their svn. If I try to compile using the sources included with pd, I get a bunch of deprecation warnings followed by a syntax error. If I update the source codes to those in portaudio's svn trunk, the syntax error goes away but there are still many deprecation warnings. But, I have audio, with and without jack.
The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the configure script reports gcc as unusable. Is there a better way to make gcc compile universal binaries?
Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner hans@at.or.atwrote:
portaudio provides CoreAudio support already. It is AudioUnit support that is in the works, which I suppose is part of CoreAudio. What are the errors with portaudio in pd-gui-rewrite? It would be good to get those fixed there, since you said that portaudio on its own can build fine for 64-bit (or am I mistaken?)
.hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as Pd-Vanilla, but I guess you aren't worried about that because you are working on getting coreaudio support (which would be nice). Jack works, everything is sounds nice and stable.
The only thing I noticed is that expr cannot be found. I have only tried a few of the example patches so far.
cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote:
Oops, my fault. I had some residual CFLAGS from trying to get Gem to compile... onward :)
On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote:
On running a regular ./configure in the gui rewrite branch, I get the error:
checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner hans@at.or.atwrote:
The build system in vanilla/extended is pretty ugly, especially for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been rewritten from scratch to be a full autotools build system. That should fix the -isysroot and --disable-portaudio problem you mention. Try it out, and we can fix any issues there.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read this and the post below...
I have been slowly figuring out the last problem, where gcc can't find my headers in /usr/include. It is because the configure line:
if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody does. I also don't know why OS X 10.6 is being detected as fat anything.
I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't find a good stdarg.h, as the one include within that sdk has a #include_next stdarg.h directive. Then, with this -sysroot flag, gcc doesn't search any other directory and none of the 20 other stdarg.h files on my computer are found. I remove this flag and the header files are found elsewhere just fine.
I compiled Portaudio from svn as universal binary with 64bit. But, this library doesn't work with Pd's portaudio source files and the new sources don't work with Pd's sources. So, I can't get past building the portaudio objects. I tried just using jack with "./configure --enable-jack --disable-portaudio", but the build script still tries to build portaudio and fails.
This is all with pd vanilla from Miller's website. I'm also trying to build the Pd extended sources, but I suppose I should start a new thread for the problem I hit there..
On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote:
Macports made me a universal binary portaudio, thankfully because I could not get it to compile as 64 bit from the source (I posted why on the portaudio mailing list).
I'm having other annoying problems with my build system, probably something very stupid that I am not aware of. Neither Pd nor Pd-extended can find header files in /usr/include. This isn't so hard to include as a CFLAGS flag, but then it still can't find stdarg.h, which just makes me think my build system is broken.
I'm working through the various errors to getting Pd-extended building on Snow Leopard as 64 bit, but I have to say I'm probably not the best candidate as this is the first mac that I've had in years. Truthfully, I was looking forward to a time when things 'just worked' :) Not there yet.
Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
It seems that portaudio should build as 64-bit, perhaps its worth trying to upgrade the portaudio files that are included in Pd-extended. I recently updated the pd-extended/0.42.5 branch to the most recent stable portaudio.
http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd-core right now. This will support the iPhone, but should also work on Mac OS X. With this, it should be possible to get working audio on Mac OS X without portaudio.
AFAIK, Fink does support 64-bit now, so as long as the libs support it, then Fink should work. I'd say it would be worthwhile building Pd-extended 64-bit without the Fink/Macports dependencies, since most included externals don't need any other libs.
.hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner <hans@at.or.at > wrote:
> > You need to set the LDFLAGS to -arch i386 also. Or even better, try > doing a 64-bit Snow Leopard build of Pd-extended. > > I'd love to try that, but I'm still working to get a 64-bit Snow Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is limited as far as I can see, so I'm having to compile each piece from source.
cheers, Rich
> .hc > > > On Nov 8, 2009, at 6:58 PM, Rich E wrote: > > I've been trying to get my externals to compile in to use with >> Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because >> Pd-extended is i386 and my externals are compiling as x86_64. >> >> All I can find on this is to force the build to i386 with the gcc >> flag '-arch i386', but the linker won't allow it: >> >> ld: warning: in incr.o, file is not of required architecture >> >> and then, I again have the 64 bit version: >> $ file incr.pd_darwin >> incr.pd_darwin: Mach-O 64-bit bundle x86_64 >> >> Anyone know how to get these guys to work with Pd-extended? >> >> Rich >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > > ---------------------------------------------------------------------------- > > I hate it when they say, "He gave his life for his country." Nobody > gives their life for anything. We steal the lives of these kids. -Admiral > Gene LeRocque > >
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
http://at.or.at/hans/
Ok, I updated the portaudio to the latest, updated 3 weeks ago in
portaudio SVN. Plus I fixed your CFLAGS bug. You should also be able
to build universal by doing "./configure --enable-universal" instead
of manually setting the CFLAGS/LDFLAGS.
.hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio
support, but haven't tested it much.To compile portaudio as 64bit, you need the the sources from their
svn. If I try to compile using the sources included with pd, I get
a bunch of deprecation warnings followed by a syntax error. If I
update the source codes to those in portaudio's svn trunk, the
syntax error goes away but there are still many deprecation
warnings. But, I have audio, with and without jack.The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the
configure script reports gcc as unusable. Is there a better way to
make gcc compile universal binaries?Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner
hans@at.or.at wrote:portaudio provides CoreAudio support already. It is AudioUnit
support that is in the works, which I suppose is part of CoreAudio.
What are the errors with portaudio in pd-gui-rewrite? It would be
good to get those fixed there, since you said that portaudio on its
own can build fine for 64-bit (or am I mistaken?).hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as
Pd-Vanilla, but I guess you aren't worried about that because you
are working on getting coreaudio support (which would be nice).
Jack works, everything is sounds nice and stable.The only thing I noticed is that expr cannot be found. I have only
tried a few of the example patches so far.cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote: Oops, my fault. I had some residual CFLAGS from trying to get Gem
to compile... onward :)On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote: On running a regular ./configure in the gui rewrite branch, I get
the error:checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui- rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
The build system in vanilla/extended is pretty ugly, especially for
Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has
been rewritten from scratch to be a full autotools build system.
That should fix the -isysroot and --disable-portaudio problem you
mention. Try it out, and we can fix any issues there.svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read
this and the post below...I have been slowly figuring out the last problem, where gcc can't
find my headers in /usr/include. It is because the configure line:if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody
does. I also don't know why OS X 10.6 is being detected as fat
anything.I can install the MacOSX10.4u.sdk from the Xcode disk, but then
gcc can't find a good stdarg.h, as the one include within that sdk
has a #include_next stdarg.h directive. Then, with this -sysroot
flag, gcc doesn't search any other directory and none of the 20
other stdarg.h files on my computer are found. I remove this flag
and the header files are found elsewhere just fine.I compiled Portaudio from svn as universal binary with 64bit.
But, this library doesn't work with Pd's portaudio source files
and the new sources don't work with Pd's sources. So, I can't get
past building the portaudio objects. I tried just using jack with
"./configure --enable-jack --disable-portaudio", but the build
script still tries to build portaudio and fails.This is all with pd vanilla from Miller's website. I'm also
trying to build the Pd extended sources, but I suppose I should
start a new thread for the problem I hit there..On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com
wrote: Macports made me a universal binary portaudio, thankfully because
I could not get it to compile as 64 bit from the source (I posted
why on the portaudio mailing list).I'm having other annoying problems with my build system, probably
something very stupid that I am not aware of. Neither Pd nor Pd- extended can find header files in /usr/include. This isn't so
hard to include as a CFLAGS flag, but then it still can't find
stdarg.h, which just makes me think my build system is broken.I'm working through the various errors to getting Pd-extended
building on Snow Leopard as 64 bit, but I have to say I'm probably
not the best candidate as this is the first mac that I've had in
years. Truthfully, I was looking forward to a time when things
'just worked' :) Not there yet.Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
It seems that portaudio should build as 64-bit, perhaps its worth
trying to upgrade the portaudio files that are included in Pd- extended. I recently updated the pd-extended/0.42.5 branch to the
most recent stable portaudio.http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd- core right now. This will support the iPhone, but should also
work on Mac OS X. With this, it should be possible to get
working audio on Mac OS X without portaudio.AFAIK, Fink does support 64-bit now, so as long as the libs
support it, then Fink should work. I'd say it would be
worthwhile building Pd-extended 64-bit without the Fink/Macports
dependencies, since most included externals don't need any other
libs..hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
You need to set the LDFLAGS to -arch i386 also. Or even better,
try doing a 64-bit Snow Leopard build of Pd-extended.I'd love to try that, but I'm still working to get a 64-bit Snow
Leopard build of Pd-vanilla. Portaudio won't let me do it yet.
Macports is limited as far as I can see, so I'm having to
compile each piece from source.cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with
Pd-extended... in OS X Snow Leopard. So far it hasn't been easy
because Pd-extended is i386 and my externals are compiling as
x86_64.All I can find on this is to force the build to i386 with the
gcc flag '-arch i386', but the linker won't allow it:ld: warning: in incr.o, file is not of required architecture
and then, I again have the 64 bit version: $ file incr.pd_darwin incr.pd_darwin: Mach-O 64-bit bundle x86_64
Anyone know how to get these guys to work with Pd-extended?
Rich _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country."
Nobody gives their life for anything. We steal the lives of
these kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." -
Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Portaudio makes now, 64bit pd. I can also make the 32bit version using CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the following error:
gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
I was thinking, what happens when you have a universal binary pd and you mix external types, like some are 32bit and some are 64bit? Maybe a universal binary pd isn't so good..
I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything strange happens.
On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Ok, I updated the portaudio to the latest, updated 3 weeks ago in portaudio SVN. Plus I fixed your CFLAGS bug. You should also be able to build universal by doing "./configure --enable-universal" instead of manually setting the CFLAGS/LDFLAGS.
.hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio support, but haven't tested it much.
To compile portaudio as 64bit, you need the the sources from their svn. If I try to compile using the sources included with pd, I get a bunch of deprecation warnings followed by a syntax error. If I update the source codes to those in portaudio's svn trunk, the syntax error goes away but there are still many deprecation warnings. But, I have audio, with and without jack.
The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the configure script reports gcc as unusable. Is there a better way to make gcc compile universal binaries?
Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner hans@at.or.atwrote:
portaudio provides CoreAudio support already. It is AudioUnit support that is in the works, which I suppose is part of CoreAudio. What are the errors with portaudio in pd-gui-rewrite? It would be good to get those fixed there, since you said that portaudio on its own can build fine for 64-bit (or am I mistaken?)
.hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as Pd-Vanilla, but I guess you aren't worried about that because you are working on getting coreaudio support (which would be nice). Jack works, everything is sounds nice and stable.
The only thing I noticed is that expr cannot be found. I have only tried a few of the example patches so far.
cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote:
Oops, my fault. I had some residual CFLAGS from trying to get Gem to compile... onward :)
On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote:
On running a regular ./configure in the gui rewrite branch, I get the error:
checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner < hans@at.or.at> wrote:
The build system in vanilla/extended is pretty ugly, especially for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been rewritten from scratch to be a full autotools build system. That should fix the -isysroot and --disable-portaudio problem you mention. Try it out, and we can fix any issues there.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read this and the post below...
I have been slowly figuring out the last problem, where gcc can't find my headers in /usr/include. It is because the configure line:
if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody does. I also don't know why OS X 10.6 is being detected as fat anything.
I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't find a good stdarg.h, as the one include within that sdk has a #include_next stdarg.h directive. Then, with this -sysroot flag, gcc doesn't search any other directory and none of the 20 other stdarg.h files on my computer are found. I remove this flag and the header files are found elsewhere just fine.
I compiled Portaudio from svn as universal binary with 64bit. But, this library doesn't work with Pd's portaudio source files and the new sources don't work with Pd's sources. So, I can't get past building the portaudio objects. I tried just using jack with "./configure --enable-jack --disable-portaudio", but the build script still tries to build portaudio and fails.
This is all with pd vanilla from Miller's website. I'm also trying to build the Pd extended sources, but I suppose I should start a new thread for the problem I hit there..
On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote:
Macports made me a universal binary portaudio, thankfully because I could not get it to compile as 64 bit from the source (I posted why on the portaudio mailing list).
I'm having other annoying problems with my build system, probably something very stupid that I am not aware of. Neither Pd nor Pd-extended can find header files in /usr/include. This isn't so hard to include as a CFLAGS flag, but then it still can't find stdarg.h, which just makes me think my build system is broken.
I'm working through the various errors to getting Pd-extended building on Snow Leopard as 64 bit, but I have to say I'm probably not the best candidate as this is the first mac that I've had in years. Truthfully, I was looking forward to a time when things 'just worked' :) Not there yet.
Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner < hans@at.or.at> wrote:
> > It seems that portaudio should build as 64-bit, perhaps its worth > trying to upgrade the portaudio files that are included in Pd-extended. I > recently updated the pd-extended/0.42.5 branch to the most recent stable > portaudio. > > > http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio > > .hc > > On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote: > > > I'm working getting an Apple AudioUnit sound API support into pd-core > right now. This will support the iPhone, but should also work on Mac OS X. > With this, it should be possible to get working audio on Mac OS X without > portaudio. > > AFAIK, Fink does support 64-bit now, so as long as the libs support > it, then Fink should work. I'd say it would be worthwhile building > Pd-extended 64-bit without the Fink/Macports dependencies, since most > included externals don't need any other libs. > > .hc > > On Nov 9, 2009, at 10:49 AM, Rich E wrote: > > Ah, that did the trick. Thanks. > > On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner < > hans@at.or.at> wrote: > >> >> You need to set the LDFLAGS to -arch i386 also. Or even better, try >> doing a 64-bit Snow Leopard build of Pd-extended. >> >> > I'd love to try that, but I'm still working to get a 64-bit Snow > Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is > limited as far as I can see, so I'm having to compile each piece from > source. > > > cheers, > Rich > > >> .hc >> >> >> On Nov 8, 2009, at 6:58 PM, Rich E wrote: >> >> I've been trying to get my externals to compile in to use with >>> Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because >>> Pd-extended is i386 and my externals are compiling as x86_64. >>> >>> All I can find on this is to force the build to i386 with the gcc >>> flag '-arch i386', but the linker won't allow it: >>> >>> ld: warning: in incr.o, file is not of required architecture >>> >>> and then, I again have the 64 bit version: >>> $ file incr.pd_darwin >>> incr.pd_darwin: Mach-O 64-bit bundle x86_64 >>> >>> Anyone know how to get these guys to work with Pd-extended? >>> >>> Rich >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >> >> >> >> ---------------------------------------------------------------------------- >> >> I hate it when they say, "He gave his life for his country." Nobody >> gives their life for anything. We steal the lives of these kids. -Admiral >> Gene LeRocque >> >> > > > > > ---------------------------------------------------------------------------- > > "Making boring techno music is really easy with modern tools," he > says, "but with live coding, boring techno is much harder." - Chris > McCormick > > > > > > > > > ---------------------------------------------------------------------------- > > Using ReBirth is like trying to play an 808 with a long stick. > -David Zicarelli > > >
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Ran into problems right after starting the program... don't know why they weren't there before, but..
If I try running pd from /usr/local/bin via 'make install', I get the following error:
Error in startup script: couldn't read file "/usr/local/lib/pd/bin/pd-gui.tcl": no such file or directory
But the tcl file is there, don't know why it can't be found.
Portaudio is failing at startup (as I said before, there are still many deprecation warnings as well, although it compiles):
Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd -------------------------------pd-gui.tcl----------------------------------- Pt_Start() called Assertion failed: (sizeof( UInt32 ) == sizeof( long )), function ringBufferIOProc, file src/hostapi/coreaudio/pa_mac_core.c, line 1722. Pd: signal 6 closing audio... Abort trap
Apparently that function isn't 64bit :)
Pd seems to work with Jack though, so I can test it through that (this is how I normally run my patches in linux anyway).
A question about settings: where are they stored in OS X if I compile from source? I know Pd-extended works with the plist system, but how about in the pd-gui-rewrite?
Rich
On Sat, Nov 14, 2009 at 4:35 PM, Rich E reakinator@gmail.com wrote:
Portaudio makes now, 64bit pd. I can also make the 32bit version using CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the following error:
gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
I was thinking, what happens when you have a universal binary pd and you mix external types, like some are 32bit and some are 64bit? Maybe a universal binary pd isn't so good..
I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything strange happens.
On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Ok, I updated the portaudio to the latest, updated 3 weeks ago in portaudio SVN. Plus I fixed your CFLAGS bug. You should also be able to build universal by doing "./configure --enable-universal" instead of manually setting the CFLAGS/LDFLAGS.
.hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio support, but haven't tested it much.
To compile portaudio as 64bit, you need the the sources from their svn. If I try to compile using the sources included with pd, I get a bunch of deprecation warnings followed by a syntax error. If I update the source codes to those in portaudio's svn trunk, the syntax error goes away but there are still many deprecation warnings. But, I have audio, with and without jack.
The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the configure script reports gcc as unusable. Is there a better way to make gcc compile universal binaries?
Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner hans@at.or.atwrote:
portaudio provides CoreAudio support already. It is AudioUnit support that is in the works, which I suppose is part of CoreAudio. What are the errors with portaudio in pd-gui-rewrite? It would be good to get those fixed there, since you said that portaudio on its own can build fine for 64-bit (or am I mistaken?)
.hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as Pd-Vanilla, but I guess you aren't worried about that because you are working on getting coreaudio support (which would be nice). Jack works, everything is sounds nice and stable.
The only thing I noticed is that expr cannot be found. I have only tried a few of the example patches so far.
cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote:
Oops, my fault. I had some residual CFLAGS from trying to get Gem to compile... onward :)
On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote:
On running a regular ./configure in the gui rewrite branch, I get the error:
checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner < hans@at.or.at> wrote:
The build system in vanilla/extended is pretty ugly, especially for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been rewritten from scratch to be a full autotools build system. That should fix the -isysroot and --disable-portaudio problem you mention. Try it out, and we can fix any issues there.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read this and the post below...
I have been slowly figuring out the last problem, where gcc can't find my headers in /usr/include. It is because the configure line:
if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody does. I also don't know why OS X 10.6 is being detected as fat anything.
I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't find a good stdarg.h, as the one include within that sdk has a #include_next stdarg.h directive. Then, with this -sysroot flag, gcc doesn't search any other directory and none of the 20 other stdarg.h files on my computer are found. I remove this flag and the header files are found elsewhere just fine.
I compiled Portaudio from svn as universal binary with 64bit. But, this library doesn't work with Pd's portaudio source files and the new sources don't work with Pd's sources. So, I can't get past building the portaudio objects. I tried just using jack with "./configure --enable-jack --disable-portaudio", but the build script still tries to build portaudio and fails.
This is all with pd vanilla from Miller's website. I'm also trying to build the Pd extended sources, but I suppose I should start a new thread for the problem I hit there..
On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote:
> Macports made me a universal binary portaudio, thankfully because I > could not get it to compile as 64 bit from the source (I posted why on the > portaudio mailing list). > > I'm having other annoying problems with my build system, probably > something very stupid that I am not aware of. Neither Pd nor Pd-extended > can find header files in /usr/include. This isn't so hard to include as a > CFLAGS flag, but then it still can't find stdarg.h, which just makes me > think my build system is broken. > > I'm working through the various errors to getting Pd-extended > building on Snow Leopard as 64 bit, but I have to say I'm probably not the > best candidate as this is the first mac that I've had in years. Truthfully, > I was looking forward to a time when things 'just worked' :) Not there yet. > > Rich > > > On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner < > hans@at.or.at> wrote: > >> >> It seems that portaudio should build as 64-bit, perhaps its worth >> trying to upgrade the portaudio files that are included in Pd-extended. I >> recently updated the pd-extended/0.42.5 branch to the most recent stable >> portaudio. >> >> >> http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio >> >> .hc >> >> On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote: >> >> >> I'm working getting an Apple AudioUnit sound API support into >> pd-core right now. This will support the iPhone, but should also work on >> Mac OS X. With this, it should be possible to get working audio on Mac OS X >> without portaudio. >> >> AFAIK, Fink does support 64-bit now, so as long as the libs support >> it, then Fink should work. I'd say it would be worthwhile building >> Pd-extended 64-bit without the Fink/Macports dependencies, since most >> included externals don't need any other libs. >> >> .hc >> >> On Nov 9, 2009, at 10:49 AM, Rich E wrote: >> >> Ah, that did the trick. Thanks. >> >> On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner < >> hans@at.or.at> wrote: >> >>> >>> You need to set the LDFLAGS to -arch i386 also. Or even better, >>> try doing a 64-bit Snow Leopard build of Pd-extended. >>> >>> >> I'd love to try that, but I'm still working to get a 64-bit Snow >> Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is >> limited as far as I can see, so I'm having to compile each piece from >> source. >> >> >> cheers, >> Rich >> >> >>> .hc >>> >>> >>> On Nov 8, 2009, at 6:58 PM, Rich E wrote: >>> >>> I've been trying to get my externals to compile in to use with >>>> Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because >>>> Pd-extended is i386 and my externals are compiling as x86_64. >>>> >>>> All I can find on this is to force the build to i386 with the gcc >>>> flag '-arch i386', but the linker won't allow it: >>>> >>>> ld: warning: in incr.o, file is not of required architecture >>>> >>>> and then, I again have the 64 bit version: >>>> $ file incr.pd_darwin >>>> incr.pd_darwin: Mach-O 64-bit bundle x86_64 >>>> >>>> Anyone know how to get these guys to work with Pd-extended? >>>> >>>> Rich >>>> _______________________________________________ >>>> Pd-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> I hate it when they say, "He gave his life for his country." >>> Nobody gives their life for anything. We steal the lives of these kids. >>> -Admiral Gene LeRocque >>> >>> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> "Making boring techno music is really easy with modern tools," he >> says, "but with live coding, boring techno is much harder." - Chris >> McCormick >> >> >> >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> Using ReBirth is like trying to play an 808 with a long stick. >> -David Zicarelli >> >> >> >
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
On Nov 14, 2009, at 11:13 AM, Rich E wrote:
Ran into problems right after starting the program... don't know why
they weren't there before, but..If I try running pd from /usr/local/bin via 'make install', I get
the following error:Error in startup script: couldn't read file "/usr/local/lib/pd/bin/ pd-gui.tcl": no such file or directory
But the tcl file is there, don't know why it can't be found.
I just tried 'make install' on Mac OS X 10.5 and it worked fine for
me. Both 'pd' alone and '/usr/local/bin/pd'
Portaudio is failing at startup (as I said before, there are still
many deprecation warnings as well, although it compiles):Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd -------------------------------pd- gui.tcl----------------------------------- Pt_Start() called Assertion failed: (sizeof( UInt32 ) == sizeof( long )), function
ringBufferIOProc, file src/hostapi/coreaudio/pa_mac_core.c, line 1722. Pd: signal 6 closing audio... Abort trapApparently that function isn't 64bit :)
Seems like a portaudio bug, it would be good to report it there.
Pd seems to work with Jack though, so I can test it through that
(this is how I normally run my patches in linux anyway).A question about settings: where are they stored in OS X if I
compile from source? I know Pd-extended works with the plist
system, but how about in the pd-gui-rewrite?
pd-gui-rewrite is roughly Pd-vanilla 0.43, so treat it accordingly.
.hc
Rich
On Sat, Nov 14, 2009 at 4:35 PM, Rich E reakinator@gmail.com wrote: Portaudio makes now, 64bit pd. I can also make the 32bit version
using CFLAGS and LDFLAGS, but the --enable-universal doesn't work
because of the following error:gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1I was thinking, what happens when you have a universal binary pd and
you mix external types, like some are 32bit and some are 64bit?
Maybe a universal binary pd isn't so good..I'll try testing out the 64bit pd-gui-rewrite for a while, see if
anything strange happens.On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner
hans@at.or.at wrote:Ok, I updated the portaudio to the latest, updated 3 weeks ago in
portaudio SVN. Plus I fixed your CFLAGS bug. You should also be
able to build universal by doing "./configure --enable-universal"
instead of manually setting the CFLAGS/LDFLAGS..hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio
support, but haven't tested it much.To compile portaudio as 64bit, you need the the sources from their
svn. If I try to compile using the sources included with pd, I get
a bunch of deprecation warnings followed by a syntax error. If I
update the source codes to those in portaudio's svn trunk, the
syntax error goes away but there are still many deprecation
warnings. But, I have audio, with and without jack.The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the
configure script reports gcc as unusable. Is there a better way to
make gcc compile universal binaries?Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner <hans@at.or.at
wrote:
portaudio provides CoreAudio support already. It is AudioUnit
support that is in the works, which I suppose is part of
CoreAudio. What are the errors with portaudio in pd-gui-rewrite?
It would be good to get those fixed there, since you said that
portaudio on its own can build fine for 64-bit (or am I mistaken?).hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as
Pd-Vanilla, but I guess you aren't worried about that because you
are working on getting coreaudio support (which would be nice).
Jack works, everything is sounds nice and stable.The only thing I noticed is that expr cannot be found. I have
only tried a few of the example patches so far.cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com
wrote: Oops, my fault. I had some residual CFLAGS from trying to get Gem
to compile... onward :)On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com
wrote: On running a regular ./configure in the gui rewrite branch, I get
the error:checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui- rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
The build system in vanilla/extended is pretty ugly, especially
for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch
has been rewritten from scratch to be a full autotools build
system. That should fix the -isysroot and --disable-portaudio
problem you mention. Try it out, and we can fix any issues there.svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio &&
make.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read
this and the post below...I have been slowly figuring out the last problem, where gcc can't
find my headers in /usr/include. It is because the configure line:if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody
does. I also don't know why OS X 10.6 is being detected as fat
anything.I can install the MacOSX10.4u.sdk from the Xcode disk, but then
gcc can't find a good stdarg.h, as the one include within that
sdk has a #include_next stdarg.h directive. Then, with this - sysroot flag, gcc doesn't search any other directory and none of
the 20 other stdarg.h files on my computer are found. I remove
this flag and the header files are found elsewhere just fine.I compiled Portaudio from svn as universal binary with 64bit.
But, this library doesn't work with Pd's portaudio source files
and the new sources don't work with Pd's sources. So, I can't
get past building the portaudio objects. I tried just using jack
with "./configure --enable-jack --disable-portaudio", but the
build script still tries to build portaudio and fails.This is all with pd vanilla from Miller's website. I'm also
trying to build the Pd extended sources, but I suppose I should
start a new thread for the problem I hit there..On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com
wrote: Macports made me a universal binary portaudio, thankfully because
I could not get it to compile as 64 bit from the source (I posted
why on the portaudio mailing list).I'm having other annoying problems with my build system, probably
something very stupid that I am not aware of. Neither Pd nor Pd- extended can find header files in /usr/include. This isn't so
hard to include as a CFLAGS flag, but then it still can't find
stdarg.h, which just makes me think my build system is broken.I'm working through the various errors to getting Pd-extended
building on Snow Leopard as 64 bit, but I have to say I'm
probably not the best candidate as this is the first mac that
I've had in years. Truthfully, I was looking forward to a time
when things 'just worked' :) Not there yet.Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
It seems that portaudio should build as 64-bit, perhaps its worth
trying to upgrade the portaudio files that are included in Pd- extended. I recently updated the pd-extended/0.42.5 branch to
the most recent stable portaudio.http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd- core right now. This will support the iPhone, but should also
work on Mac OS X. With this, it should be possible to get
working audio on Mac OS X without portaudio.AFAIK, Fink does support 64-bit now, so as long as the libs
support it, then Fink should work. I'd say it would be
worthwhile building Pd-extended 64-bit without the Fink/Macports
dependencies, since most included externals don't need any other
libs..hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner <hans@at.or.at > wrote:
You need to set the LDFLAGS to -arch i386 also. Or even
better, try doing a 64-bit Snow Leopard build of Pd-extended.I'd love to try that, but I'm still working to get a 64-bit
Snow Leopard build of Pd-vanilla. Portaudio won't let me do it
yet. Macports is limited as far as I can see, so I'm having to
compile each piece from source.cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with
Pd-extended... in OS X Snow Leopard. So far it hasn't been easy
because Pd-extended is i386 and my externals are compiling as
x86_64.All I can find on this is to force the build to i386 with the
gcc flag '-arch i386', but the linker won't allow it:ld: warning: in incr.o, file is not of required architecture
and then, I again have the 64 bit version: $ file incr.pd_darwin incr.pd_darwin: Mach-O 64-bit bundle x86_64
Anyone know how to get these guys to work with Pd-extended?
Rich _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country."
Nobody gives their life for anything. We steal the lives of
these kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." -
Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick.
-David Zicarelli
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja
Kahf
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith
On Sat, Nov 14, 2009 at 6:17 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On Nov 14, 2009, at 11:13 AM, Rich E wrote:
Ran into problems right after starting the program... don't know why they weren't there before, but..
If I try running pd from /usr/local/bin via 'make install', I get the following error:
Error in startup script: couldn't read file "/usr/local/lib/pd/bin/pd-gui.tcl": no such file or directory
But the tcl file is there, don't know why it can't be found.
I just tried 'make install' on Mac OS X 10.5 and it worked fine for me. Both 'pd' alone and '/usr/local/bin/pd'
Actually, "/usr/local/lib/pd/bin/pd-gui.tcl" is not there, but "/usr/local/bin/pd-gui.tcl" is. I think it is just getting installed to the wrong directory.
Portaudio is failing at startup (as I said before, there are still many deprecation warnings as well, although it compiles):
Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd
-------------------------------pd-gui.tcl----------------------------------- Pt_Start() called Assertion failed: (sizeof( UInt32 ) == sizeof( long )), function ringBufferIOProc, file src/hostapi/coreaudio/pa_mac_core.c, line 1722. Pd: signal 6 closing audio... Abort trap
Apparently that function isn't 64bit :)
Seems like a portaudio bug, it would be good to report it there.
Reported.
Pd seems to work with Jack though, so I can test it through that (this is how I normally run my patches in linux anyway).
A question about settings: where are they stored in OS X if I compile from source? I know Pd-extended works with the plist system, but how about in the pd-gui-rewrite?
pd-gui-rewrite is roughly Pd-vanilla 0.43, so treat it accordingly.
.hc
One other thing, now when I try to run ./pd -jack, I get:
Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd -jack -------------------------------pd-gui.tcl----------------------------------- Pt_Start() called jack_client_new: deprecated ERROR: 'pd' never showed up, 'pd-gui' quitting!
I'd like to help more, but I seem to be spending alot of time hopelessly trying to get 64bit to work when I don't even see why 64bit is better than 32bit (in pd's case).
Rich
On Sat, Nov 14, 2009 at 4:35 PM, Rich E reakinator@gmail.com wrote:
Portaudio makes now, 64bit pd. I can also make the 32bit version using CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the following error:
gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
I was thinking, what happens when you have a universal binary pd and you mix external types, like some are 32bit and some are 64bit? Maybe a universal binary pd isn't so good..
I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything strange happens.
On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Ok, I updated the portaudio to the latest, updated 3 weeks ago in portaudio SVN. Plus I fixed your CFLAGS bug. You should also be able to build universal by doing "./configure --enable-universal" instead of manually setting the CFLAGS/LDFLAGS.
.hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio support, but haven't tested it much.
To compile portaudio as 64bit, you need the the sources from their svn. If I try to compile using the sources included with pd, I get a bunch of deprecation warnings followed by a syntax error. If I update the source codes to those in portaudio's svn trunk, the syntax error goes away but there are still many deprecation warnings. But, I have audio, with and without jack.
The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the configure script reports gcc as unusable. Is there a better way to make gcc compile universal binaries?
Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner hans@at.or.atwrote:
portaudio provides CoreAudio support already. It is AudioUnit support that is in the works, which I suppose is part of CoreAudio. What are the errors with portaudio in pd-gui-rewrite? It would be good to get those fixed there, since you said that portaudio on its own can build fine for 64-bit (or am I mistaken?)
.hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as Pd-Vanilla, but I guess you aren't worried about that because you are working on getting coreaudio support (which would be nice). Jack works, everything is sounds nice and stable.
The only thing I noticed is that expr cannot be found. I have only tried a few of the example patches so far.
cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote:
Oops, my fault. I had some residual CFLAGS from trying to get Gem to compile... onward :)
On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote:
On running a regular ./configure in the gui rewrite branch, I get the error:
checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner < hans@at.or.at> wrote:
> > The build system in vanilla/extended is pretty ugly, especially for > Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been > rewritten from scratch to be a full autotools build system. That should fix > the -isysroot and --disable-portaudio problem you mention. Try it out, and > we can fix any issues there. > > svn co > https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... > cd 0.43 > ./autogen.sh && ./configure --enable-jack --disable-portaudio && make > > .hc > > On Nov 11, 2009, at 6:08 PM, Rich E wrote: > > Oops, I accidentally just sent my last post to Hans. Please read > this and the post below... > > I have been slowly figuring out the last problem, where gcc can't > find my headers in /usr/include. It is because the configure line: > > if test "x$fat" == "xyes"; > then > MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
> -arch i386 -arch ppc -Wno-error" > > First, I don't know why this is necessary, but I'm sure somebody > does. I also don't know why OS X 10.6 is being detected as fat anything. > > I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc > can't find a good stdarg.h, as the one include within that sdk has a > #include_next stdarg.h directive. Then, with this -sysroot flag, gcc > doesn't search any other directory and none of the 20 other stdarg.h files > on my computer are found. I remove this flag and the header files are found > elsewhere just fine. > > I compiled Portaudio from svn as universal binary with 64bit. But, > this library doesn't work with Pd's portaudio source files and the new > sources don't work with Pd's sources. So, I can't get past building the > portaudio objects. I tried just using jack with "./configure --enable-jack > --disable-portaudio", but the build script still tries to build portaudio > and fails. > > This is all with pd vanilla from Miller's website. I'm also trying > to build the Pd extended sources, but I suppose I should start a new thread > for the problem I hit there.. > > On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.comwrote: > >> Macports made me a universal binary portaudio, thankfully because I >> could not get it to compile as 64 bit from the source (I posted why on the >> portaudio mailing list). >> >> I'm having other annoying problems with my build system, probably >> something very stupid that I am not aware of. Neither Pd nor Pd-extended >> can find header files in /usr/include. This isn't so hard to include as a >> CFLAGS flag, but then it still can't find stdarg.h, which just makes me >> think my build system is broken. >> >> I'm working through the various errors to getting Pd-extended >> building on Snow Leopard as 64 bit, but I have to say I'm probably not the >> best candidate as this is the first mac that I've had in years. Truthfully, >> I was looking forward to a time when things 'just worked' :) Not there yet. >> >> Rich >> >> >> On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner < >> hans@at.or.at> wrote: >> >>> >>> It seems that portaudio should build as 64-bit, perhaps its worth >>> trying to upgrade the portaudio files that are included in Pd-extended. I >>> recently updated the pd-extended/0.42.5 branch to the most recent stable >>> portaudio. >>> >>> >>> http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio >>> >>> .hc >>> >>> On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote: >>> >>> >>> I'm working getting an Apple AudioUnit sound API support into >>> pd-core right now. This will support the iPhone, but should also work on >>> Mac OS X. With this, it should be possible to get working audio on Mac OS X >>> without portaudio. >>> >>> AFAIK, Fink does support 64-bit now, so as long as the libs support >>> it, then Fink should work. I'd say it would be worthwhile building >>> Pd-extended 64-bit without the Fink/Macports dependencies, since most >>> included externals don't need any other libs. >>> >>> .hc >>> >>> On Nov 9, 2009, at 10:49 AM, Rich E wrote: >>> >>> Ah, that did the trick. Thanks. >>> >>> On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner < >>> hans@at.or.at> wrote: >>> >>>> >>>> You need to set the LDFLAGS to -arch i386 also. Or even better, >>>> try doing a 64-bit Snow Leopard build of Pd-extended. >>>> >>>> >>> I'd love to try that, but I'm still working to get a 64-bit Snow >>> Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is >>> limited as far as I can see, so I'm having to compile each piece from >>> source. >>> >>> >>> cheers, >>> Rich >>> >>> >>>> .hc >>>> >>>> >>>> On Nov 8, 2009, at 6:58 PM, Rich E wrote: >>>> >>>> I've been trying to get my externals to compile in to use with >>>>> Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because >>>>> Pd-extended is i386 and my externals are compiling as x86_64. >>>>> >>>>> All I can find on this is to force the build to i386 with the gcc >>>>> flag '-arch i386', but the linker won't allow it: >>>>> >>>>> ld: warning: in incr.o, file is not of required architecture >>>>> >>>>> and then, I again have the 64 bit version: >>>>> $ file incr.pd_darwin >>>>> incr.pd_darwin: Mach-O 64-bit bundle x86_64 >>>>> >>>>> Anyone know how to get these guys to work with Pd-extended? >>>>> >>>>> Rich >>>>> _______________________________________________ >>>>> Pd-list@iem.at mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> http://lists.puredata.info/listinfo/pd-list >>>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> I hate it when they say, "He gave his life for his country." >>>> Nobody gives their life for anything. We steal the lives of these kids. >>>> -Admiral Gene LeRocque >>>> >>>> >>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> "Making boring techno music is really easy with modern tools," he >>> says, "but with live coding, boring techno is much harder." - Chris >>> McCormick >>> >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> Using ReBirth is like trying to play an 808 with a long stick. >>> -David Zicarelli >>> >>> >>> >> > > > > > > > ---------------------------------------------------------------------------- > > 'You people have such restrictive dress for women,’ she said, > hobbling away in three inch heels and panty hose to finish out another > pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf > > >
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
On Sat, Nov 14, 2009 at 7:30 PM, Rich E reakinator@gmail.com wrote:
On Sat, Nov 14, 2009 at 6:17 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On Nov 14, 2009, at 11:13 AM, Rich E wrote:
Ran into problems right after starting the program... don't know why they weren't there before, but..
If I try running pd from /usr/local/bin via 'make install', I get the following error:
Error in startup script: couldn't read file "/usr/local/lib/pd/bin/pd-gui.tcl": no such file or directory
But the tcl file is there, don't know why it can't be found.
I just tried 'make install' on Mac OS X 10.5 and it worked fine for me. Both 'pd' alone and '/usr/local/bin/pd'
Actually, "/usr/local/lib/pd/bin/pd-gui.tcl" is not there, but "/usr/local/bin/pd-gui.tcl" is. I think it is just getting installed to the wrong directory.
Portaudio is failing at startup (as I said before, there are still many deprecation warnings as well, although it compiles):
Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd
-------------------------------pd-gui.tcl----------------------------------- Pt_Start() called Assertion failed: (sizeof( UInt32 ) == sizeof( long )), function ringBufferIOProc, file src/hostapi/coreaudio/pa_mac_core.c, line 1722. Pd: signal 6 closing audio... Abort trap
Apparently that function isn't 64bit :)
Seems like a portaudio bug, it would be good to report it there.
Reported.
After they give me a patch, the problem seemed to magically go away (pd 64bit is running on my system with portaudio/coreaudio).
Another question: even if I run "./pd -portaudio", I get the following output:
ConnectPort: can't find mach server port name = jackdmp_entry.501_default err = unknown error code Cannot connect to server Mach port jack server is not running or cannot be started no message buffer overruns JAR: jack server not running?
But then, pd starts with portaudio as the driver. Why is there an attempt to start jack if portaudio is specified?
Rich
Pd seems to work with Jack though, so I can test it through that (this is how I normally run my patches in linux anyway).
A question about settings: where are they stored in OS X if I compile from source? I know Pd-extended works with the plist system, but how about in the pd-gui-rewrite?
pd-gui-rewrite is roughly Pd-vanilla 0.43, so treat it accordingly.
.hc
One other thing, now when I try to run ./pd -jack, I get:
Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd -jack
-------------------------------pd-gui.tcl----------------------------------- Pt_Start() called jack_client_new: deprecated ERROR: 'pd' never showed up, 'pd-gui' quitting!
I'd like to help more, but I seem to be spending alot of time hopelessly trying to get 64bit to work when I don't even see why 64bit is better than 32bit (in pd's case).
Rich
On Sat, Nov 14, 2009 at 4:35 PM, Rich E reakinator@gmail.com wrote:
Portaudio makes now, 64bit pd. I can also make the 32bit version using CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the following error:
gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
I was thinking, what happens when you have a universal binary pd and you mix external types, like some are 32bit and some are 64bit? Maybe a universal binary pd isn't so good..
I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything strange happens.
On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Ok, I updated the portaudio to the latest, updated 3 weeks ago in portaudio SVN. Plus I fixed your CFLAGS bug. You should also be able to build universal by doing "./configure --enable-universal" instead of manually setting the CFLAGS/LDFLAGS.
.hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio support, but haven't tested it much.
To compile portaudio as 64bit, you need the the sources from their svn. If I try to compile using the sources included with pd, I get a bunch of deprecation warnings followed by a syntax error. If I update the source codes to those in portaudio's svn trunk, the syntax error goes away but there are still many deprecation warnings. But, I have audio, with and without jack.
The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the configure script reports gcc as unusable. Is there a better way to make gcc compile universal binaries?
Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner hans@at.or.atwrote:
portaudio provides CoreAudio support already. It is AudioUnit support that is in the works, which I suppose is part of CoreAudio. What are the errors with portaudio in pd-gui-rewrite? It would be good to get those fixed there, since you said that portaudio on its own can build fine for 64-bit (or am I mistaken?)
.hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as Pd-Vanilla, but I guess you aren't worried about that because you are working on getting coreaudio support (which would be nice). Jack works, everything is sounds nice and stable.
The only thing I noticed is that expr cannot be found. I have only tried a few of the example patches so far.
cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote:
Oops, my fault. I had some residual CFLAGS from trying to get Gem to compile... onward :)
On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote:
> On running a regular ./configure in the gui rewrite branch, I get the > error: > > checking for C compiler default output file name... > configure: error: in >
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': > configure: error: C compiler cannot create executables > Seeconfig.log' for more details. > > I attached the config.log, any ideas? > > Rich > > > On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner < > hans@at.or.at> wrote: > >> >> The build system in vanilla/extended is pretty ugly, especially for >> Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been >> rewritten from scratch to be a full autotools build system. That should fix >> the -isysroot and --disable-portaudio problem you mention. Try it out, and >> we can fix any issues there. >> >> svn co >> https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... >> cd 0.43 >> ./autogen.sh && ./configure --enable-jack --disable-portaudio && >> make >> >> .hc >> >> On Nov 11, 2009, at 6:08 PM, Rich E wrote: >> >> Oops, I accidentally just sent my last post to Hans. Please read >> this and the post below... >> >> I have been slowly figuring out the last problem, where gcc can't >> find my headers in /usr/include. It is because the configure line: >> >> if test "x$fat" == "xyes"; >> then >> MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
>> -arch i386 -arch ppc -Wno-error" >> >> First, I don't know why this is necessary, but I'm sure somebody >> does. I also don't know why OS X 10.6 is being detected as fat anything. >> >> I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc >> can't find a good stdarg.h, as the one include within that sdk has a >> #include_next stdarg.h directive. Then, with this -sysroot flag, gcc >> doesn't search any other directory and none of the 20 other stdarg.h files >> on my computer are found. I remove this flag and the header files are found >> elsewhere just fine. >> >> I compiled Portaudio from svn as universal binary with 64bit. But, >> this library doesn't work with Pd's portaudio source files and the new >> sources don't work with Pd's sources. So, I can't get past building the >> portaudio objects. I tried just using jack with "./configure --enable-jack >> --disable-portaudio", but the build script still tries to build portaudio >> and fails. >> >> This is all with pd vanilla from Miller's website. I'm also trying >> to build the Pd extended sources, but I suppose I should start a new thread >> for the problem I hit there.. >> >> On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.comwrote: >> >>> Macports made me a universal binary portaudio, thankfully because I >>> could not get it to compile as 64 bit from the source (I posted why on the >>> portaudio mailing list). >>> >>> I'm having other annoying problems with my build system, probably >>> something very stupid that I am not aware of. Neither Pd nor Pd-extended >>> can find header files in /usr/include. This isn't so hard to include as a >>> CFLAGS flag, but then it still can't find stdarg.h, which just makes me >>> think my build system is broken. >>> >>> I'm working through the various errors to getting Pd-extended >>> building on Snow Leopard as 64 bit, but I have to say I'm probably not the >>> best candidate as this is the first mac that I've had in years. Truthfully, >>> I was looking forward to a time when things 'just worked' :) Not there yet. >>> >>> Rich >>> >>> >>> On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner < >>> hans@at.or.at> wrote: >>> >>>> >>>> It seems that portaudio should build as 64-bit, perhaps its worth >>>> trying to upgrade the portaudio files that are included in Pd-extended. I >>>> recently updated the pd-extended/0.42.5 branch to the most recent stable >>>> portaudio. >>>> >>>> >>>> http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio >>>> >>>> .hc >>>> >>>> On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote: >>>> >>>> >>>> I'm working getting an Apple AudioUnit sound API support into >>>> pd-core right now. This will support the iPhone, but should also work on >>>> Mac OS X. With this, it should be possible to get working audio on Mac OS X >>>> without portaudio. >>>> >>>> AFAIK, Fink does support 64-bit now, so as long as the libs >>>> support it, then Fink should work. I'd say it would be worthwhile building >>>> Pd-extended 64-bit without the Fink/Macports dependencies, since most >>>> included externals don't need any other libs. >>>> >>>> .hc >>>> >>>> On Nov 9, 2009, at 10:49 AM, Rich E wrote: >>>> >>>> Ah, that did the trick. Thanks. >>>> >>>> On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner < >>>> hans@at.or.at> wrote: >>>> >>>>> >>>>> You need to set the LDFLAGS to -arch i386 also. Or even better, >>>>> try doing a 64-bit Snow Leopard build of Pd-extended. >>>>> >>>>> >>>> I'd love to try that, but I'm still working to get a 64-bit Snow >>>> Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is >>>> limited as far as I can see, so I'm having to compile each piece from >>>> source. >>>> >>>> >>>> cheers, >>>> Rich >>>> >>>> >>>>> .hc >>>>> >>>>> >>>>> On Nov 8, 2009, at 6:58 PM, Rich E wrote: >>>>> >>>>> I've been trying to get my externals to compile in to use with >>>>>> Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because >>>>>> Pd-extended is i386 and my externals are compiling as x86_64. >>>>>> >>>>>> All I can find on this is to force the build to i386 with the >>>>>> gcc flag '-arch i386', but the linker won't allow it: >>>>>> >>>>>> ld: warning: in incr.o, file is not of required architecture >>>>>> >>>>>> and then, I again have the 64 bit version: >>>>>> $ file incr.pd_darwin >>>>>> incr.pd_darwin: Mach-O 64-bit bundle x86_64 >>>>>> >>>>>> Anyone know how to get these guys to work with Pd-extended? >>>>>> >>>>>> Rich >>>>>> _______________________________________________ >>>>>> Pd-list@iem.at mailing list >>>>>> UNSUBSCRIBE and account-management -> >>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> I hate it when they say, "He gave his life for his country." >>>>> Nobody gives their life for anything. We steal the lives of these kids. >>>>> -Admiral Gene LeRocque >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> "Making boring techno music is really easy with modern tools," he >>>> >>>> says, "but with live coding, boring techno is much harder." - >>>> Chris McCormick >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> Using ReBirth is like trying to play an 808 with a long stick. >>>> -David Zicarelli >>>> >>>> >>>> >>> >> >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> 'You people have such restrictive dress for women,’ she said, >> hobbling away in three inch heels and panty hose to finish out another >> pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf >> >> >> >
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
I forgot. In order to build a Universal, you need to include -- disable-dependency-tracking. So like this:
./configure --disable-dependency-tracking --enable-universal
My guess is that a universal Pd running in 64-bit mode will fail to
load a 32-bit external.
.hc
On Nov 14, 2009, at 10:35 AM, Rich E wrote:
Portaudio makes now, 64bit pd. I can also make the 32bit version
using CFLAGS and LDFLAGS, but the --enable-universal doesn't work
because of the following error:gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1I was thinking, what happens when you have a universal binary pd and
you mix external types, like some are 32bit and some are 64bit?
Maybe a universal binary pd isn't so good..I'll try testing out the 64bit pd-gui-rewrite for a while, see if
anything strange happens.On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner
hans@at.or.at wrote:Ok, I updated the portaudio to the latest, updated 3 weeks ago in
portaudio SVN. Plus I fixed your CFLAGS bug. You should also be
able to build universal by doing "./configure --enable-universal"
instead of manually setting the CFLAGS/LDFLAGS..hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio
support, but haven't tested it much.To compile portaudio as 64bit, you need the the sources from their
svn. If I try to compile using the sources included with pd, I get
a bunch of deprecation warnings followed by a syntax error. If I
update the source codes to those in portaudio's svn trunk, the
syntax error goes away but there are still many deprecation
warnings. But, I have audio, with and without jack.The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the
configure script reports gcc as unusable. Is there a better way to
make gcc compile universal binaries?Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner <hans@at.or.at
wrote:
portaudio provides CoreAudio support already. It is AudioUnit
support that is in the works, which I suppose is part of
CoreAudio. What are the errors with portaudio in pd-gui-rewrite?
It would be good to get those fixed there, since you said that
portaudio on its own can build fine for 64-bit (or am I mistaken?).hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as
Pd-Vanilla, but I guess you aren't worried about that because you
are working on getting coreaudio support (which would be nice).
Jack works, everything is sounds nice and stable.The only thing I noticed is that expr cannot be found. I have
only tried a few of the example patches so far.cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com
wrote: Oops, my fault. I had some residual CFLAGS from trying to get Gem
to compile... onward :)On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com
wrote: On running a regular ./configure in the gui rewrite branch, I get
the error:checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui- rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
The build system in vanilla/extended is pretty ugly, especially
for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch
has been rewritten from scratch to be a full autotools build
system. That should fix the -isysroot and --disable-portaudio
problem you mention. Try it out, and we can fix any issues there.svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio &&
make.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read
this and the post below...I have been slowly figuring out the last problem, where gcc can't
find my headers in /usr/include. It is because the configure line:if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody
does. I also don't know why OS X 10.6 is being detected as fat
anything.I can install the MacOSX10.4u.sdk from the Xcode disk, but then
gcc can't find a good stdarg.h, as the one include within that
sdk has a #include_next stdarg.h directive. Then, with this - sysroot flag, gcc doesn't search any other directory and none of
the 20 other stdarg.h files on my computer are found. I remove
this flag and the header files are found elsewhere just fine.I compiled Portaudio from svn as universal binary with 64bit.
But, this library doesn't work with Pd's portaudio source files
and the new sources don't work with Pd's sources. So, I can't
get past building the portaudio objects. I tried just using jack
with "./configure --enable-jack --disable-portaudio", but the
build script still tries to build portaudio and fails.This is all with pd vanilla from Miller's website. I'm also
trying to build the Pd extended sources, but I suppose I should
start a new thread for the problem I hit there..On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com
wrote: Macports made me a universal binary portaudio, thankfully because
I could not get it to compile as 64 bit from the source (I posted
why on the portaudio mailing list).I'm having other annoying problems with my build system, probably
something very stupid that I am not aware of. Neither Pd nor Pd- extended can find header files in /usr/include. This isn't so
hard to include as a CFLAGS flag, but then it still can't find
stdarg.h, which just makes me think my build system is broken.I'm working through the various errors to getting Pd-extended
building on Snow Leopard as 64 bit, but I have to say I'm
probably not the best candidate as this is the first mac that
I've had in years. Truthfully, I was looking forward to a time
when things 'just worked' :) Not there yet.Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
It seems that portaudio should build as 64-bit, perhaps its worth
trying to upgrade the portaudio files that are included in Pd- extended. I recently updated the pd-extended/0.42.5 branch to
the most recent stable portaudio.http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into pd- core right now. This will support the iPhone, but should also
work on Mac OS X. With this, it should be possible to get
working audio on Mac OS X without portaudio.AFAIK, Fink does support 64-bit now, so as long as the libs
support it, then Fink should work. I'd say it would be
worthwhile building Pd-extended 64-bit without the Fink/Macports
dependencies, since most included externals don't need any other
libs..hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
Ah, that did the trick. Thanks.
On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner <hans@at.or.at > wrote:
You need to set the LDFLAGS to -arch i386 also. Or even
better, try doing a 64-bit Snow Leopard build of Pd-extended.I'd love to try that, but I'm still working to get a 64-bit
Snow Leopard build of Pd-vanilla. Portaudio won't let me do it
yet. Macports is limited as far as I can see, so I'm having to
compile each piece from source.cheers, Rich
.hc
On Nov 8, 2009, at 6:58 PM, Rich E wrote:
I've been trying to get my externals to compile in to use with
Pd-extended... in OS X Snow Leopard. So far it hasn't been easy
because Pd-extended is i386 and my externals are compiling as
x86_64.All I can find on this is to force the build to i386 with the
gcc flag '-arch i386', but the linker won't allow it:ld: warning: in incr.o, file is not of required architecture
and then, I again have the 64 bit version: $ file incr.pd_darwin incr.pd_darwin: Mach-O 64-bit bundle x86_64
Anyone know how to get these guys to work with Pd-extended?
Rich _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country."
Nobody gives their life for anything. We steal the lives of
these kids. -Admiral Gene LeRocque
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." -
Chris McCormick
Using ReBirth is like trying to play an 808 with a long stick.
-David Zicarelli
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja
Kahf
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Information wants to be free. -Stewart Brand
My system doesn't want to compile for ppc64 (I have no idea what type of mac needs this):
macosx-version-min=10.5 -c porttime/ptmacosx_cf.c -fno-common -DPIC -o .libs/ptmacosx_cf.o In file included from /usr/include/mach/mach_interface.h:50, from /usr/include/mach/mach.h:67, from porttime/ptmacosx_cf.c:8: /usr/include/mach/task.h:35:29: error: mach/ppc64/task.h: No such file or directory In file included from /usr/include/mach/mach_interface.h:51, from /usr/include/mach/mach.h:67, from porttime/ptmacosx_cf.c:8: /usr/include/mach/thread_act.h:35:35: error: mach/ppc64/thread_act.h: No such file or directory lipo: can't figure out the architecture type of: /var/folders/mi/miOJDQB4G4W+2Le0+GFkPk+++TI/-Tmp-//ccEWxRNK.out make[2]: *** [ptmacosx_cf.lo] Error 1
On Sat, Nov 14, 2009 at 6:10 PM, Hans-Christoph Steiner hans@at.or.atwrote:
I forgot. In order to build a Universal, you need to include --disable-dependency-tracking. So like this:
./configure --disable-dependency-tracking --enable-universal
My guess is that a universal Pd running in 64-bit mode will fail to load a 32-bit external.
.hc
On Nov 14, 2009, at 10:35 AM, Rich E wrote:
Portaudio makes now, 64bit pd. I can also make the 32bit version using CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the following error:
gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
I was thinking, what happens when you have a universal binary pd and you mix external types, like some are 32bit and some are 64bit? Maybe a universal binary pd isn't so good..
I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything strange happens.
On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Ok, I updated the portaudio to the latest, updated 3 weeks ago in portaudio SVN. Plus I fixed your CFLAGS bug. You should also be able to build universal by doing "./configure --enable-universal" instead of manually setting the CFLAGS/LDFLAGS.
.hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio support, but haven't tested it much.
To compile portaudio as 64bit, you need the the sources from their svn. If I try to compile using the sources included with pd, I get a bunch of deprecation warnings followed by a syntax error. If I update the source codes to those in portaudio's svn trunk, the syntax error goes away but there are still many deprecation warnings. But, I have audio, with and without jack.
The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the configure script reports gcc as unusable. Is there a better way to make gcc compile universal binaries?
Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner hans@at.or.atwrote:
portaudio provides CoreAudio support already. It is AudioUnit support that is in the works, which I suppose is part of CoreAudio. What are the errors with portaudio in pd-gui-rewrite? It would be good to get those fixed there, since you said that portaudio on its own can build fine for 64-bit (or am I mistaken?)
.hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as Pd-Vanilla, but I guess you aren't worried about that because you are working on getting coreaudio support (which would be nice). Jack works, everything is sounds nice and stable.
The only thing I noticed is that expr cannot be found. I have only tried a few of the example patches so far.
cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com wrote:
Oops, my fault. I had some residual CFLAGS from trying to get Gem to compile... onward :)
On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com wrote:
On running a regular ./configure in the gui rewrite branch, I get the error:
checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner < hans@at.or.at> wrote:
The build system in vanilla/extended is pretty ugly, especially for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch has been rewritten from scratch to be a full autotools build system. That should fix the -isysroot and --disable-portaudio problem you mention. Try it out, and we can fix any issues there.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please read this and the post below...
I have been slowly figuring out the last problem, where gcc can't find my headers in /usr/include. It is because the configure line:
if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody does. I also don't know why OS X 10.6 is being detected as fat anything.
I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't find a good stdarg.h, as the one include within that sdk has a #include_next stdarg.h directive. Then, with this -sysroot flag, gcc doesn't search any other directory and none of the 20 other stdarg.h files on my computer are found. I remove this flag and the header files are found elsewhere just fine.
I compiled Portaudio from svn as universal binary with 64bit. But, this library doesn't work with Pd's portaudio source files and the new sources don't work with Pd's sources. So, I can't get past building the portaudio objects. I tried just using jack with "./configure --enable-jack --disable-portaudio", but the build script still tries to build portaudio and fails.
This is all with pd vanilla from Miller's website. I'm also trying to build the Pd extended sources, but I suppose I should start a new thread for the problem I hit there..
On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com wrote:
> Macports made me a universal binary portaudio, thankfully because I > could not get it to compile as 64 bit from the source (I posted why on the > portaudio mailing list). > > I'm having other annoying problems with my build system, probably > something very stupid that I am not aware of. Neither Pd nor Pd-extended > can find header files in /usr/include. This isn't so hard to include as a > CFLAGS flag, but then it still can't find stdarg.h, which just makes me > think my build system is broken. > > I'm working through the various errors to getting Pd-extended > building on Snow Leopard as 64 bit, but I have to say I'm probably not the > best candidate as this is the first mac that I've had in years. Truthfully, > I was looking forward to a time when things 'just worked' :) Not there yet. > > Rich > > > On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner < > hans@at.or.at> wrote: > >> >> It seems that portaudio should build as 64-bit, perhaps its worth >> trying to upgrade the portaudio files that are included in Pd-extended. I >> recently updated the pd-extended/0.42.5 branch to the most recent stable >> portaudio. >> >> >> http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio >> >> .hc >> >> On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote: >> >> >> I'm working getting an Apple AudioUnit sound API support into >> pd-core right now. This will support the iPhone, but should also work on >> Mac OS X. With this, it should be possible to get working audio on Mac OS X >> without portaudio. >> >> AFAIK, Fink does support 64-bit now, so as long as the libs support >> it, then Fink should work. I'd say it would be worthwhile building >> Pd-extended 64-bit without the Fink/Macports dependencies, since most >> included externals don't need any other libs. >> >> .hc >> >> On Nov 9, 2009, at 10:49 AM, Rich E wrote: >> >> Ah, that did the trick. Thanks. >> >> On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner < >> hans@at.or.at> wrote: >> >>> >>> You need to set the LDFLAGS to -arch i386 also. Or even better, >>> try doing a 64-bit Snow Leopard build of Pd-extended. >>> >>> >> I'd love to try that, but I'm still working to get a 64-bit Snow >> Leopard build of Pd-vanilla. Portaudio won't let me do it yet. Macports is >> limited as far as I can see, so I'm having to compile each piece from >> source. >> >> >> cheers, >> Rich >> >> >>> .hc >>> >>> >>> On Nov 8, 2009, at 6:58 PM, Rich E wrote: >>> >>> I've been trying to get my externals to compile in to use with >>>> Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because >>>> Pd-extended is i386 and my externals are compiling as x86_64. >>>> >>>> All I can find on this is to force the build to i386 with the gcc >>>> flag '-arch i386', but the linker won't allow it: >>>> >>>> ld: warning: in incr.o, file is not of required architecture >>>> >>>> and then, I again have the 64 bit version: >>>> $ file incr.pd_darwin >>>> incr.pd_darwin: Mach-O 64-bit bundle x86_64 >>>> >>>> Anyone know how to get these guys to work with Pd-extended? >>>> >>>> Rich >>>> _______________________________________________ >>>> Pd-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> I hate it when they say, "He gave his life for his country." >>> Nobody gives their life for anything. We steal the lives of these kids. >>> -Admiral Gene LeRocque >>> >>> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> "Making boring techno music is really easy with modern tools," he >> says, "but with live coding, boring techno is much harder." - Chris >> McCormick >> >> >> >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> Using ReBirth is like trying to play an 808 with a long stick. >> -David Zicarelli >> >> >> >
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Information wants to be free. -Stewart Brand
ppc64 is a G5.
.hc
On Nov 14, 2009, at 1:18 PM, Rich E wrote:
My system doesn't want to compile for ppc64 (I have no idea what
type of mac needs this):macosx-version-min=10.5 -c porttime/ptmacosx_cf.c -fno-common -DPIC
-o .libs/ptmacosx_cf.o In file included from /usr/include/mach/mach_interface.h:50, from /usr/include/mach/mach.h:67, from porttime/ptmacosx_cf.c:8: /usr/include/mach/task.h:35:29: error: mach/ppc64/task.h: No such
file or directory In file included from /usr/include/mach/mach_interface.h:51, from /usr/include/mach/mach.h:67, from porttime/ptmacosx_cf.c:8: /usr/include/mach/thread_act.h:35:35: error: mach/ppc64/ thread_act.h: No such file or directory lipo: can't figure out the architecture type of: /var/folders/mi/ miOJDQB4G4W+2Le0+GFkPk+++TI/-Tmp-//ccEWxRNK.out make[2]: *** [ptmacosx_cf.lo] Error 1On Sat, Nov 14, 2009 at 6:10 PM, Hans-Christoph Steiner
hans@at.or.at wrote:I forgot. In order to build a Universal, you need to include -- disable-dependency-tracking. So like this:
./configure --disable-dependency-tracking --enable-universal
My guess is that a universal Pd running in 64-bit mode will fail to
load a 32-bit external..hc
On Nov 14, 2009, at 10:35 AM, Rich E wrote:
Portaudio makes now, 64bit pd. I can also make the 32bit version
using CFLAGS and LDFLAGS, but the --enable-universal doesn't work
because of the following error:gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1I was thinking, what happens when you have a universal binary pd
and you mix external types, like some are 32bit and some are
64bit? Maybe a universal binary pd isn't so good..I'll try testing out the 64bit pd-gui-rewrite for a while, see if
anything strange happens.On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
Ok, I updated the portaudio to the latest, updated 3 weeks ago in
portaudio SVN. Plus I fixed your CFLAGS bug. You should also be
able to build universal by doing "./configure --enable-universal"
instead of manually setting the CFLAGS/LDFLAGS..hc
On Nov 13, 2009, at 2:03 PM, Rich E wrote:
I compiled the pd-gui-rewrite branch today as 64bit with portaudio
support, but haven't tested it much.To compile portaudio as 64bit, you need the the sources from their
svn. If I try to compile using the sources included with pd, I
get a bunch of deprecation warnings followed by a syntax error.
If I update the source codes to those in portaudio's svn trunk,
the syntax error goes away but there are still many deprecation
warnings. But, I have audio, with and without jack.The configure script doesn't like it when I do: export CFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-arch i386 -arch x86_64"
This is how I compiled portaudio, but when I do it with pd, the
configure script reports gcc as unusable. Is there a better way
to make gcc compile universal binaries?Rich
On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner <hans@at.or.at
wrote:
portaudio provides CoreAudio support already. It is AudioUnit
support that is in the works, which I suppose is part of
CoreAudio. What are the errors with portaudio in pd-gui-rewrite?
It would be good to get those fixed there, since you said that
portaudio on its own can build fine for 64-bit (or am I mistaken?).hc
On Nov 11, 2009, at 8:21 PM, Rich E wrote:
Got it compiled and it looks nice. The portaudio failed, same as
Pd-Vanilla, but I guess you aren't worried about that because you
are working on getting coreaudio support (which would be nice).
Jack works, everything is sounds nice and stable.The only thing I noticed is that expr cannot be found. I have
only tried a few of the example patches so far.cheers, Rich
On Thu, Nov 12, 2009 at 1:57 AM, Rich E reakinator@gmail.com
wrote: Oops, my fault. I had some residual CFLAGS from trying to get
Gem to compile... onward :)On Thu, Nov 12, 2009 at 1:23 AM, Rich E reakinator@gmail.com
wrote: On running a regular ./configure in the gui rewrite branch, I get
the error:checking for C compiler default output file name... configure: error: in
/Users/richardeakin/Downloads/src/pd-gui- rewrite-0.43': configure: error: C compiler cannot create executables Seeconfig.log' for more details.I attached the config.log, any ideas?
Rich
On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
The build system in vanilla/extended is pretty ugly, especially
for Mac OS X. The build system in the pd-gui-rewrite/0.43 branch
has been rewritten from scratch to be a full autotools build
system. That should fix the -isysroot and --disable-portaudio
problem you mention. Try it out, and we can fix any issues there.svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewr... cd 0.43 ./autogen.sh && ./configure --enable-jack --disable-portaudio &&
make.hc
On Nov 11, 2009, at 6:08 PM, Rich E wrote:
Oops, I accidentally just sent my last post to Hans. Please
read this and the post below...I have been slowly figuring out the last problem, where gcc
can't find my headers in /usr/include. It is because the
configure line:if test "x$fat" == "xyes"; then MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-arch i386 -arch ppc -Wno-error"First, I don't know why this is necessary, but I'm sure somebody
does. I also don't know why OS X 10.6 is being detected as fat
anything.I can install the MacOSX10.4u.sdk from the Xcode disk, but then
gcc can't find a good stdarg.h, as the one include within that
sdk has a #include_next stdarg.h directive. Then, with this - sysroot flag, gcc doesn't search any other directory and none of
the 20 other stdarg.h files on my computer are found. I remove
this flag and the header files are found elsewhere just fine.I compiled Portaudio from svn as universal binary with 64bit.
But, this library doesn't work with Pd's portaudio source files
and the new sources don't work with Pd's sources. So, I can't
get past building the portaudio objects. I tried just using
jack with "./configure --enable-jack --disable-portaudio", but
the build script still tries to build portaudio and fails.This is all with pd vanilla from Miller's website. I'm also
trying to build the Pd extended sources, but I suppose I should
start a new thread for the problem I hit there..On Tue, Nov 10, 2009 at 3:29 AM, Rich E reakinator@gmail.com
wrote: Macports made me a universal binary portaudio, thankfully
because I could not get it to compile as 64 bit from the source
(I posted why on the portaudio mailing list).I'm having other annoying problems with my build system,
probably something very stupid that I am not aware of. Neither
Pd nor Pd-extended can find header files in /usr/include. This
isn't so hard to include as a CFLAGS flag, but then it still
can't find stdarg.h, which just makes me think my build system
is broken.I'm working through the various errors to getting Pd-extended
building on Snow Leopard as 64 bit, but I have to say I'm
probably not the best candidate as this is the first mac that
I've had in years. Truthfully, I was looking forward to a time
when things 'just worked' :) Not there yet.Rich
On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
It seems that portaudio should build as 64-bit, perhaps its
worth trying to upgrade the portaudio files that are included in
Pd-extended. I recently updated the pd-extended/0.42.5 branch
to the most recent stable portaudio.http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
.hc
On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
I'm working getting an Apple AudioUnit sound API support into
pd-core right now. This will support the iPhone, but should
also work on Mac OS X. With this, it should be possible to get
working audio on Mac OS X without portaudio.AFAIK, Fink does support 64-bit now, so as long as the libs
support it, then Fink should work. I'd say it would be
worthwhile building Pd-extended 64-bit without the Fink/ Macports dependencies, since most included externals don't need
any other libs..hc
On Nov 9, 2009, at 10:49 AM, Rich E wrote:
> Ah, that did the trick. Thanks. > > On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner <hans@at.or.at > > wrote: > > You need to set the LDFLAGS to -arch i386 also. Or even
> better, try doing a 64-bit Snow Leopard build of Pd-extended. > > > I'd love to try that, but I'm still working to get a 64-bit
> Snow Leopard build of Pd-vanilla. Portaudio won't let me do
> it yet. Macports is limited as far as I can see, so I'm
> having to compile each piece from source. > > > cheers, > Rich > > .hc > > > On Nov 8, 2009, at 6:58 PM, Rich E wrote: > > I've been trying to get my externals to compile in to use with
> Pd-extended... in OS X Snow Leopard. So far it hasn't been
> easy because Pd-extended is i386 and my externals are
> compiling as x86_64. > > All I can find on this is to force the build to i386 with the
> gcc flag '-arch i386', but the linker won't allow it: > > ld: warning: in incr.o, file is not of required architecture > > and then, I again have the 64 bit version: > $ file incr.pd_darwin > incr.pd_darwin: Mach-O 64-bit bundle x86_64 > > Anyone know how to get these guys to work with Pd-extended? > > Rich > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > ---------------------------------------------------------------------------- > > I hate it when they say, "He gave his life for his country."
> Nobody gives their life for anything. We steal the lives of
> these kids. -Admiral Gene LeRocque > >
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." -
Chris McCormick
Using ReBirth is like trying to play an 808 with a long
stick. -David Zicarelli
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja
Kahf
http://at.or.at/hans/
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Information wants to be free. -Stewart Brand
If you are not part of the solution, you are part of the problem.
-
Hans-Christoph Steiner -
Rich E