Re: [PD] Building externals on OSX
On Oct 22, 2013, at 2:52 PM, Dan Wilcox wrote: On Oct 22, 2013, at 1:07 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] Building externals on OSX Date: October 22, 2013 1:14:41 PM EDT To: pd-list@iem.at On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Yes. It's a different instruction set and Rosetta, the PCC compatibility layer, won't run an OSX 10.7+. Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Your political bias notwithstanding (I say use what works for you), I have a 4 year old Apple laptop that still does everything I need with the latest version of OSX and I plan to upgrade to OSX Mavericks when it comes out. That's pretty good, as I had a job when I bought it and I am currently an unemployed artist working on his thesis right now, so it's good this sleek and sexy device is not yet an ugly, unprofitable one. As with anything, not everyone buys the newest one every iteration and I can say, without any hardware issues whatsoever so far, I got what I paid for. In any case, I've long thought of helping with the OSX compatibility for Pd (updating GEM to Cocoa/64 bit for instance) but I honestly don't have the time or support right now. Maybe next spring I can do a reverse kickstarter? Pd could definitely use help on Mac OS X. Especially since I've switched to Linux Mint as my desktop OS. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 10/22/2013 05:34 PM, Dan Wilcox wrote: I'm not going to argue OS politics, again use what works best for you. I can understand the frustration with how the build system works on OSX. It is actually really nice in a lot of ways but it took me a while to get the hang of it after switching from Linux. Without counting Debian, I still think there's really no need at this point to support a PPC build for OSX. When I wrote drop PPC support in earlier emails, I was referring only to OSX. I understand. It just seemed you were explaining why PPC is no longer supported as the natural outgrowth of software development progress. I mentioned Debian both because I'm curious if anyone runs it on PPC, and also as a counter-example to the type of development model Apple uses. (One which is able to support a much wider variety of architectures at a fraction of the cost.) A longer discussion of OS politics is probably an unnecessary digression here: both you and I are building things in OSX, and that won't change by pointing out differences in our philosophy for why we do it. But I just wanted to point out that use what works for you should expand to use what works for you without creating a moral hazard for all of us. One doesn't need to use the language of free software advocates in order to do that, but free software is undoubtedly part of any viable solution. If the internet that connects all these devices weren't actively being weaponized I probably wouldn't quibble over this. Well, I might, but it'd feel more like a pasttime and less like a necessity. :) The code as it is now should compile just fine on Debian PPC since the only architecture differences as far as I know would be compiling for little endian versus big endian on Intel. I don't think there are any architecture specific assembly / function calls in Pd. So in the end, dropping OSX PPC support helps in simplifying the build scripts at least. Again, I think there's really no need to host newer Pd OSX PPC binaries, just leave the last one there since anyone using it will be on a much older version of OSX anyway. Ok, that sounds like the way to go then. -Jonathan On Oct 22, 2013, at 5:05 PM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% Thanks. Those are low numbers, but I'd imagine the number of PPC users is still fairly high: http://www.statisticbrain.com/apple-computer-company-statistics/ I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) Your political bias notwithstanding (I say use what works for you), Well, I'd call it a political stance. And where it seemed quirky and deeply personal when I first adopted it, it now seems simply to be a restatement of the scientific method for computer security, at a time when there have been revelations that show our computers really need to be as secure as possible against attacks. I'd also point out that yours is a political stance. While I understand it, I must disagree with it because in terms of security it is much more difficult to use the scientific method to check whether the specs actually fit the implementation. In some cases on proprietary OSes neither are known so you're forced to reverse engineer the software, and for complex systems that's too time consuming and expensive to do. Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. -Jonathan On Oct 21, 2013, at 9:12 PM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: *From:*Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com *Subject:**Re: [PD] Building externals on OSX* *Date:*October 21, 2013 4:20:55 PM EDT *To:*pd-list@iem.at mailto:pd-list@iem.at On 10/21/2013 02:09 PM, Hans-Christoph Steiner wrote: That sounds like you're building pd/extra from Pd-vanilla. I never had any luck with that build system. That's part of the reason why I ripped out extra from Pd-extended and made it a standalone library. It was much easier to make it work that way. Figured this one out, too. It was a problem of building 64 bit binaries-- I just ended up building for i386 and the problem went away. If I'm going to go to the trouble of building for both architectures, then I might as well go ahead and build ppc, too. So the real solution would be for me to remove my current xcode setup and read all the stackoverflow workarounds telling which older XCode version to setup an environment that supports building for ppc. -Jonathan Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 2013-10-22 13:14, Jonathan Wilkes wrote: On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. I think Apple hardware has a MTBF of about 3 years; their business model relies on customers junking the old model at ever increasing rates and buying the new one. The old one after all never quite worked properly because they sold it before it was ready. I have a bunch of old Macs around here that mostly won't start up anymore. Usually the hard drive or the power supply fails. Good luck replacing either. I'm pissed because I've lost a lot of my work that way and with the constant incompatibility from one version of MacOS to the next not to mention the uninteroperability with any other OS. So anyway PPC is obsolete and such a machine trying to run a new version of any software would probably choke on it anyway. And OSX on PPC was really slow, system9 worked better. I think the best thing is to not upgrade at all and try to keep it running the old software while not stressing the hardware in any way. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On Oct 22, 2013, at 1:07 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] Building externals on OSX Date: October 22, 2013 1:14:41 PM EDT To: pd-list@iem.at On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Yes. It's a different instruction set and Rosetta, the PCC compatibility layer, won't run an OSX 10.7+. Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Your political bias notwithstanding (I say use what works for you), I have a 4 year old Apple laptop that still does everything I need with the latest version of OSX and I plan to upgrade to OSX Mavericks when it comes out. That's pretty good, as I had a job when I bought it and I am currently an unemployed artist working on his thesis right now, so it's good this sleek and sexy device is not yet an ugly, unprofitable one. As with anything, not everyone buys the newest one every iteration and I can say, without any hardware issues whatsoever so far, I got what I paid for. In any case, I've long thought of helping with the OSX compatibility for Pd (updating GEM to Cocoa/64 bit for instance) but I honestly don't have the time or support right now. Maybe next spring I can do a reverse kickstarter? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
The best approach might be to just support all proprietary OSes by compiling Pd to emscripten and building an interface using one of the various html5canvas/svg javascript libraries. Then, when the EME DRM hooks get forced into html5, use them to require a pay-walled subscription infrastructure on anyone not using a free software operating system. One could essentially do it by packaging some DRM blobs for Debian non-free and various other distros (Ubuntu PPAs, etc.). Then, like Apple, every time Pd gets updated, change the API for the blob. Free software OS users would automatically get it with their system update (or by downloading the newest Pd binary)-- when they want to run Pd through the browser the EME infrastructure sends the blob a puzzle and the blob sends back the answer that lets users run Pd-on-the-web without any limits or pay-wall. (Either once per session or sending it periodically.) Of course you'd get some perturbed Mac devs who could just try to remove the DRM hooks, but that's the reason to get a few extremely broad patents on some of the fundamental aspects of the way the message dispatcher speaks to the gui (or something else similarly trivial) and just threaten anyone who tries to remove the arbitrary restrictions with lawsuits. Besides, you'd only charge an _extremely_ modest fee per month in order to real-time DSP in the cloud on proprietary OS. After all it costs money to develop software, and if those users want unrestricted access and lower latency they can install a free software OS and get it for _free_. I wouldn't want to go through the trouble of doing this, but it's a fun thought experiment to twist idiotic technologies and counterproductive business models in the interest of freedom and sharing. Best, Jonathan - Original Message - From: Martin Peach martin.pe...@sympatico.ca To: Jonathan Wilkes jancs...@yahoo.com; pd-list@iem.at Cc: Sent: Tuesday, October 22, 2013 1:53 PM Subject: Re: [PD] Building externals on OSX On 2013-10-22 13:14, Jonathan Wilkes wrote: On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. I think Apple hardware has a MTBF of about 3 years; their business model relies on customers junking the old model at ever increasing rates and buying the new one. The old one after all never quite worked properly because they sold it before it was ready. I have a bunch of old Macs around here that mostly won't start up anymore. Usually the hard drive or the power supply fails. Good luck replacing either. I'm pissed because I've lost a lot of my work that way and with the constant incompatibility from one version of MacOS to the next not to mention the uninteroperability with any other OS. So anyway PPC is obsolete and such a machine trying to run a new version of any software would probably choke on it anyway. And OSX on PPC was really slow, system9 worked better. I think the best thing is to not upgrade at all and try to keep it running the old software while not stressing the hardware in any way. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 10/22/2013 02:52 PM, Dan Wilcox wrote: On Oct 22, 2013, at 1:07 PM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: *From:*Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com *Subject:**Re: [PD] Building externals on OSX* *Date:*October 22, 2013 1:14:41 PM EDT *To:*pd-list@iem.at mailto:pd-list@iem.at On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Yes. It's a different instruction set and Rosetta, the PCC compatibility layer, won't run an OSX 10.7+. Well, if it's an enormous amount of trouble to continue supporting it then I can see dropping it. Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% Thanks. Those are low numbers, but I'd imagine the number of PPC users is still fairly high: http://www.statisticbrain.com/apple-computer-company-statistics/ I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) Your political bias notwithstanding (I say use what works for you), Well, I'd call it a political stance. And where it seemed quirky and deeply personal when I first adopted it, it now seems simply to be a restatement of the scientific method for computer security, at a time when there have been revelations that show our computers really need to be as secure as possible against attacks. I'd also point out that yours is a political stance. While I understand it, I must disagree with it because in terms of security it is much more difficult to use the scientific method to check whether the specs actually fit the implementation. In some cases on proprietary OSes neither are known so you're forced to reverse engineer the software, and for complex systems that's too time consuming and expensive to do. I have a 4 year old Apple laptop that still does everything I need with the latest version of OSX and I plan to upgrade to OSX Mavericks when it comes out. That's pretty good, as I had a job when I bought it and I am currently an unemployed artist working on his thesis right now, so it's good this sleek and sexy device is not yet an ugly, unprofitable one. As with anything, not everyone buys the newest one every iteration and I can say, without any hardware issues whatsoever so far, I got what I paid for. In any case, I've long thought of helping with the OSX compatibility for Pd (updating GEM to Cocoa/64 bit for instance) but I honestly don't have the time or support right now. Maybe next spring I can do a reverse kickstarter? It's probably a much better idea to just do a Kickstarter. :) Best, Jonathan Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
I'm not going to argue OS politics, again use what works best for you. I can understand the frustration with how the build system works on OSX. It is actually really nice in a lot of ways but it took me a while to get the hang of it after switching from Linux. Without counting Debian, I still think there's really no need at this point to support a PPC build for OSX. When I wrote drop PPC support in earlier emails, I was referring only to OSX. The code as it is now should compile just fine on Debian PPC since the only architecture differences as far as I know would be compiling for little endian versus big endian on Intel. I don't think there are any architecture specific assembly / function calls in Pd. So in the end, dropping OSX PPC support helps in simplifying the build scripts at least. Again, I think there's really no need to host newer Pd OSX PPC binaries, just leave the last one there since anyone using it will be on a much older version of OSX anyway. On Oct 22, 2013, at 5:05 PM, pd-list-requ...@iem.at wrote: Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% Thanks. Those are low numbers, but I'd imagine the number of PPC users is still fairly high: http://www.statisticbrain.com/apple-computer-company-statistics/ I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) Your political bias notwithstanding (I say use what works for you), Well, I'd call it a political stance. And where it seemed quirky and deeply personal when I first adopted it, it now seems simply to be a restatement of the scientific method for computer security, at a time when there have been revelations that show our computers really need to be as secure as possible against attacks. I'd also point out that yours is a political stance. While I understand it, I must disagree with it because in terms of security it is much more difficult to use the scientific method to check whether the specs actually fit the implementation. In some cases on proprietary OSes neither are known so you're forced to reverse engineer the software, and for complex systems that's too time consuming and expensive to do. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 23/10/13 05:12, Jonathan Wilkes wrote: Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) I don't think their main ppc target is Apples now, and the Open Firmware boot system is very old, I think you need to go back a few versions to get a debian installer that still does that, then maybe you can upgrade from there, but I imagine newer ppc stuff won't be using altivec, and without altivec and the quicktime stuff optimised for it they are not so useful, really it is probably much more sensible to run OSX 10.4.9 on them and a pd that runs on that. I have an old ppc mac-mini still running from the days I used OSX, it is running an old debian. I never bought any intel macs, but certainly it took years before the intel mac-minis caught up to the speed of the G4 ones in terms of editing and playing video. Back in early Final Cut Pro days the ppc apples could run video editing much better than anything else even close to the price, but that is ancient history now and Apple mostly sells hand-held gadgets now. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
That sounds like you're building pd/extra from Pd-vanilla. I never had any luck with that build system. That's part of the reason why I ripped out extra from Pd-extended and made it a standalone library. It was much easier to make it work that way. .hc On 10/10/2013 01:08 PM, Jonathan Wilkes wrote: Hi list, Another roadblock: When I compile the externals in extra and try to create them I get an error to the Pd console: load_object: Symbol choice_setup not found In the choice directory there is a choice.d_fat and a choice.pd_darwin. nm choice/choice.d_fat shows a line with this: 0e54 T _choice_setup and nm choice/choice.pd_darwin shows a line with this: 06c0 T _choice_setup If I rename one or the other I still get the same error to the console. Same for all the other objects in extra. Same whether I prefix them with the libdir name or not. Same if I put a [declare -path .] in a patch and put it in the extra directory. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 10/21/2013 02:09 PM, Hans-Christoph Steiner wrote: That sounds like you're building pd/extra from Pd-vanilla. I never had any luck with that build system. That's part of the reason why I ripped out extra from Pd-extended and made it a standalone library. It was much easier to make it work that way. Figured this one out, too. It was a problem of building 64 bit binaries-- I just ended up building for i386 and the problem went away. If I'm going to go to the trouble of building for both architectures, then I might as well go ahead and build ppc, too. So the real solution would be for me to remove my current xcode setup and read all the stackoverflow workarounds telling which older XCode version to setup an environment that supports building for ppc. -Jonathan .hc On 10/10/2013 01:08 PM, Jonathan Wilkes wrote: Hi list, Another roadblock: When I compile the externals in extra and try to create them I get an error to the Pd console: load_object: Symbol choice_setup not found In the choice directory there is a choice.d_fat and a choice.pd_darwin. nm choice/choice.d_fat shows a line with this: 0e54 T _choice_setup and nm choice/choice.pd_darwin shows a line with this: 06c0 T _choice_setup If I rename one or the other I still get the same error to the console. Same for all the other objects in extra. Same whether I prefix them with the libdir name or not. Same if I put a [declare -path .] in a patch and put it in the extra directory. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. On Oct 21, 2013, at 9:12 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] Building externals on OSX Date: October 21, 2013 4:20:55 PM EDT To: pd-list@iem.at On 10/21/2013 02:09 PM, Hans-Christoph Steiner wrote: That sounds like you're building pd/extra from Pd-vanilla. I never had any luck with that build system. That's part of the reason why I ripped out extra from Pd-extended and made it a standalone library. It was much easier to make it work that way. Figured this one out, too. It was a problem of building 64 bit binaries-- I just ended up building for i386 and the problem went away. If I'm going to go to the trouble of building for both architectures, then I might as well go ahead and build ppc, too. So the real solution would be for me to remove my current xcode setup and read all the stackoverflow workarounds telling which older XCode version to setup an environment that supports building for ppc. -Jonathan Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
THat agrees with my experience I compile Pd vanlla on a 32-bit machine running 10.4 (I believe) and it's perfectly happy to grind out 3-architecture binary externs. (If you look in 32-bit Pd vanilla you'll see that sigmund~, etc, are OK fro PPC, i386, or whatever-you-call-it 64 bit intel. (Only gotcha is taht I can't compile teh 64 bit app that way - I have to squat on a newer machine for that, so teh exxterns included with 64 bit Pd vanilla are lacking PPC support. I don't know of any way to compile PPC apps anymore. I would be happy to put out a PPC version of Pd if I could. cheers Miller On Mon, Oct 21, 2013 at 09:38:06PM -0400, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. On Oct 21, 2013, at 9:12 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] Building externals on OSX Date: October 21, 2013 4:20:55 PM EDT To: pd-list@iem.at On 10/21/2013 02:09 PM, Hans-Christoph Steiner wrote: That sounds like you're building pd/extra from Pd-vanilla. I never had any luck with that build system. That's part of the reason why I ripped out extra from Pd-extended and made it a standalone library. It was much easier to make it work that way. Figured this one out, too. It was a problem of building 64 bit binaries-- I just ended up building for i386 and the problem went away. If I'm going to go to the trouble of building for both architectures, then I might as well go ahead and build ppc, too. So the real solution would be for me to remove my current xcode setup and read all the stackoverflow workarounds telling which older XCode version to setup an environment that supports building for ppc. -Jonathan Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
Except that that old version of Xcode/gcc doesn't have all the nice SDK stuff in the newer versions of OSX nor any of the optimizations performed by llvm ... On Oct 21, 2013, at 10:03 PM, Miller Puckette m...@ucsd.edu wrote: THat agrees with my experience I compile Pd vanlla on a 32-bit machine running 10.4 (I believe) and it's perfectly happy to grind out 3-architecture binary externs. (If you look in 32-bit Pd vanilla you'll see that sigmund~, etc, are OK fro PPC, i386, or whatever-you-call-it 64 bit intel. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
True... I tried recompilnig wth LLVM to see what I was missing out on and didn't see any significant performance difference. And the less I'm using of anyone's SDK the happier I am because they always just change again later anyway :) M On Mon, Oct 21, 2013 at 10:05:46PM -0400, Dan Wilcox wrote: Except that that old version of Xcode/gcc doesn't have all the nice SDK stuff in the newer versions of OSX nor any of the optimizations performed by llvm ... On Oct 21, 2013, at 10:03 PM, Miller Puckette m...@ucsd.edu wrote: THat agrees with my experience I compile Pd vanlla on a 32-bit machine running 10.4 (I believe) and it's perfectly happy to grind out 3-architecture binary externs. (If you look in 32-bit Pd vanilla you'll see that sigmund~, etc, are OK fro PPC, i386, or whatever-you-call-it 64 bit intel. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Building externals on OSX
Hi list, Another roadblock: When I compile the externals in extra and try to create them I get an error to the Pd console: load_object: Symbol choice_setup not found In the choice directory there is a choice.d_fat and a choice.pd_darwin. nm choice/choice.d_fat shows a line with this: 0e54 T _choice_setup and nm choice/choice.pd_darwin shows a line with this: 06c0 T _choice_setup If I rename one or the other I still get the same error to the console. Same for all the other objects in extra. Same whether I prefix them with the libdir name or not. Same if I put a [declare -path .] in a patch and put it in the extra directory. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
