« first day    last day (18 days later) » 

02:35
Grepping nvram -p doesn't find 'boot-args', 'arm64e', or 'amfi'. I Booted into recovery mode and successfully issued csrutil disable, and rebooted. Still getting same results from ./authorize_terminal.
Useful? dyld[1760]: tried: './mysay.dylib' (fat file, but missing compatible architecture (have 'x86_64,arm64e', need '')), '/System/Volumes/Preboot/Cryptexes/OS./mysay.dylib' (no such file), './mysay.dylib' (fat file, but missing compatible architecture (have 'x86_64,arm64e', need '')),
Above was from DYLD_INSERT_LIBRARIES=./mysay.dylib say -v Chap "text to speak" -e path.caf
02:48
I tried to understand the difference between arm64 and arm64e but it's way beyond me, so don't assume I'm doing the right thing! :-)
 
9 hours later…
11:28
I see... you can try adding the arm64 ABI and remove File Integrity validation in boot-args: sudo nvram boot-args="-arm64e_preview_abi amfi_get_out_of_my_way=0x1" and then reboot
you are on a M1 Mac, right?
11:47
arm64 and arm64e are slightly different architectures, different sets of instructions sent to the machine to perform tasks. When you compile a program for a specific architecture, the compiler creates machine code using the sets of instructions (0s and 1s) that the architecture understands. If an executable is compiled for one architecture and you try to load a library (additional code) of a different architecture, the machine complains about incompatible architectures.
 
3 hours later…
15:10
Success on all counts! (Yes, am on Macbook Air 2020 M1.) This is great; thanks for all your efforts.
15:28
Question: currently the speech is sent to both the speakers (in real time) and to the -e file.caf, which slows the overall operation to that of speech. I don't see any say options (other than -o) that bypass the audio production; is there a way for this solution to render the sound file without concurrently speaking it?

« first day    last day (18 days later) »