[PD-dev] Macs to transition to ARM processors

Dan Wilcox danomatika at gmail.com
Wed Jun 24 16:00:11 CEST 2020


> On Jun 24, 2020, at 12:00 PM, pd-dev-request at lists.iem.at wrote:

> so running on all
> architectures ever supported by OSX (modulo system libraries...).

To be pedantic, it has been officially "macOS" for some years now. The upcoming version will be 11.0, so "OS X" will no longer be relevant anyway.

> why not just add arm64 to that list?

I was only musing that the "Universal 2" format *might* be new. I haven't read any of the details about it yet. Hopefully it's the same thing with just the new architecture.

> so initially, I was going to rebuke the idea oft a d_fat2 format.
> 
> apple's labelling as "Universal 2" is a bit concerning though...
> 
> anyhow, I don't really see why apple should make a 2nd universal format.
> iirc, "fat" is a technology from NextStep, so its well aged, and has
> proven itself.
> this of course is no reason to not drop it.

I mentioned that it *might* be different as there was some talk about Rosetta 2 and the other emulation/virtualization layers having some sort of way to optimize existing binaries for the different architecture, which led me to think that they might rework the "fat" approach with some additions or changes to facilitate this and/or lay the groundwork for the next 10-20 years.

OTOH I also cannot imagine them changing something as fundamental as this unless it's *really* necessary.

> more important: can you (well: they) make money with a new format?
> i'm having a hard time here to imagine how (but then: i'm not very good
> in imagining how to make money in general).

(The following is not to IOhannes in particular.)

As per the usual Apple grumbling I will say "nobody is forcing people to buy an Apple product." Supporting is another story, but now there are people like me to help and I don't often feel so welcome when the platform I'm explicitly contributing a good amount of time toward is often bashed by people who don't prefer to use it. If support is a pain, then those institutions relying on Macs, of which there are many, could maybe kick back some development support in some way or even a build machine or two...

> i don't think there are still enough ppc users left for apple to care
> about them.
> thinkgs might be different with i386 though.

The last 32-bit only Intel Macs are from the late 00s, so there are some but their numbers are probably lower than you may think. There are probably fewer 32-bit Intel Macs in use now than ppc I bet, at least as far as Pd is concerned.

> however, i guess the biggest issue is for the developers it's getting
> really hard to create fat binaries that cover more architectures than
> x86_64 and i-arm64.
> that's because there's no reasonable toolchains available that allow you
> to do so.

Right. I imagine we are looking at a minimum of needing the Xcode12 developer tools (ie. compiler chain), without the Xcode UI.

> so the only way to produce fat binaries (that include mor ethan x86_&4
> and amd64) is to have multiple build systems (parts of them unsupported
> by now) and combine the artifacts into a single binary in a second step.

I think it's better to have separate builds, which we already have. It's already hard enough, especially concerning Tcl/Tk frameworks, that I do not think making "one app bundle to rule them all" is even practical... feasible perhaps, but not sustainable.

> that sounds like a big enough hurdle to be a rather plump nudge for most
> applications to support only "recent" architecture. no need to invent a
> new format.



--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20200624/e3f5d20f/attachment-0001.html>


More information about the Pd-dev mailing list