On 11/11/2024 13:19, rolfm@dds.nl wrote:

hi,

i'm (trying to) work with "all-in" patches: a folder containing a main patch, and subfolders for all abstractions and all nescesary externals for different architectures. this works well with comport, iemguts, zexy (up until now) because the object files have different extensions for each architecture.

recently i needed [binfile] and here i struck a problem: the most recent version on Deken binfile.pd_darwin works on mac M1, but not on an older Mac. there's a old [binfile] version (2015) with the same name and extension, which works on the older Mac, but not on the M1.

could i solve this by using different extensions, if yes, which ones?

http://msp.ucsd.edu/Pd_documentation/resources/chapter4.htm#s4.1.2.1

i think the only problematic case is if you have multiple fat (multi-arch) binaries for the same OS/Pd, where the architectures do not overlap. e.g. if you have a fat "binfile" that works on both PowerPC and i386, and another fat "binfile" that works an x86_64 and apple silicon, you can (obviously) not name both binfile.d_fat. you *could* get away with naming one binfile.pd_darwin and the other one binfile.d_fat (but i haven't actually tested this). the safe side is to just provide one of the fat binaries under multiple single-cpu filenames (e.g. binfile.d_arm64 and binfile.d_amd64).

also note that the filename extensions that include floatsizes (e.g. ".linux-arm64-32.so") can only be used with Pd>=0.54 or so. this is typically not a problem for Pd64 builds, but for legacy installations of single-precision Pd you might want to avoid this extension for now.

dsmar IOhannes