On Mar 30, 2022, at 4:54 PM, Alexandre Torres Porres porres@gmail.com wrote:
Guess what? A few minutes later I wrote this, I got this email message "I'm writing because I'm using a new computer with an M1 processor and I don't seem to be able to open your library anymore with Pd 0.52.2 "
So, yeah, someone downloaded the new version and couldn't run my library anymore and was wondering why they got 'broken' and it felt it wasn't supported for Pd 0.52-2 :)
That reiterates my point that externals need to be recompiled. Until then, forward the info about forcing Rosetta via the checkbox. If they were running with Rosetta before via an x86_64 build before, then they wouldn't notice a difference afterwards.
On Mar 30, 2022, at 3:12 PM, Alexandre Torres Porres porres@gmail.com wrote:
Em qua., 30 de mar. de 2022 às 06:17, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu: I don't understand your reasoning why "separate binaries make more sense." I don't recall the previous Pd & Pd-extended ppc / i386 / x86_64 mac builds being a major issue.
Not long ago, we had separate Vanilla binaries for i386 / x86_64 mac builds in Miller's site. There was a consideration that the 'i386' was there to run 'old i386 externals'. I think something like that makes sense. I can see people being thrown off by downloading the app and then not finding much externals and asking around.
You are mixing two scenarios:
- separate architecture builds
- separate OS version builds
We are dealing with an architecture transition right now (x86_64 to arm64) which is largely solved except for externals. The same has been true for other software, ala audio plugins, just that people went through this a year earlier since most of that software was updated before Pd has been.
The OS version builds are more due to older versions of Tk not working well on new systems and newer versions of Tk not working on older systems. Around macO 10.15, it came to a point to where we *had* to have a separate build.
Also just because there is link with the text "for loading old, 32-bit external libraries" doesn't, in my opinion, automatically require a new link with "for loading Intel 64-bit external libraries". We provide the universal build already. The rest is really up to Miller if he wants to provide yet another separate build...
If you are referring to external support, yes most externals need to be recompiled as fat x86_64 / arm, then they are good to go for the foreseeable future.
yeah, recompiling should be the main concern. I'm currently using mac intel machines running 10.14.6, so I'm still not ready to compile for apple silicon, but I'll install a newer system so I can do this now that the binary is out there. Hopefully someone can compile the current last versions of Cyclone and ELSE and help me with that by giving them to me so I can upload them to deken (it seems someone was doing that for Cyclone just now). Anyway, I'll also take the opportunity to ship new releases of Cyclone and ELSE before I can update my system to compile modern fat binaries in a week or so.
You don't need an M1 cpu to build for arm64. I believe this as brought up on the list already, but you can tell pd-lib-builder to make a fat build on your system with:
make -arch x86_64 arm64
That's it. Then repackage for deken and upload.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/