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-request@iem.at wrote:
From: Jonathan Wilkes jancsika@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
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-request@iem.at wrote:
From: Jonathan Wilkes jancsika@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
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 msp@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
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 msp@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
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-request@iem.at mailto:pd-list-request@iem.at wrote:
*From:*Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@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
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
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.peach@sympatico.ca To: Jonathan Wilkes jancsika@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
-
Dan Wilcox -
Jonathan Wilkes -
Martin Peach -
Miller Puckette