yzwduck

没装 Xcode: 终端跑 sudo spindump, 建议提前开好 root 权限的 shell, 遇到问题马上执行 spindump.

有装 Xcode: 打开 Instruments.app, Recording Options 里的 Global Options 的 Recording Mode 选 Last xxx seconds.

ARM 版 macOS 强制关机时, 它会在 /Library/Logs/DiagnosticReports 路径下生成一个 reset-xxx.ips 的文件 (或者按时间排序, 找 1MB 以上的文件), 里面记录了强制关机前所有进程+内核的线程堆栈信息. 如果有这文件的话, 应该能找到非常关键的信息.

原文底下有评论说了正解: 需要 jailbreak.

macOS 上禁用 SIP 来获取 task_for_pid 权限只会影响运行在 macOS 上的程序, e.g., simulator 下的 app; 如果需要真机调试的话, 需要在 iOS 上获取进程的 task_for_pid 权限. 在目标 app 没有 get-task-allow 的 entitlement 前提下, 只有 jailbreak 这条路 (虽然还有 Apple Security Research Device Program, 但他们一定知道这问题的答案).

我觉得这可能不是 efistub 而是 Unified Kernel Image? 参见 https://wiki.archlinux.org/title/Unified_kernel_image 与 https://www.phoronix.com/news/Fedora-38-Unified-Kernel-Part-1

我因为 Linux 下 4k 屏幕的缩放效果不理想而一直在用 Windows:
* 如何原生渲染 4k @ 150% 缩放;
* 如何同时使用两个不同缩放的显示器 (4k@150%, 4k@200%).

如果有解决方法 (Gnome/KDE/Sway 均可) 的话, 不胜感激.

可能是执行 install_name_tool 的时机不对.

MachO 外部依赖项的路径是编译链接时的动态库里存储的 id 值, 所以需要在编译链接 heif-enc 之前修改 libaom.3.dylib 的 id.
执行时机正确的话, otool -L libaom.3.dylib 和 heif-enc 的输出里不会出现 rpath.

你指定的 5 个环境变量中, 前 4 个与 rpath 没有关联: PATH 只影响 execve, 下面 3 个是修改编译选项的, 不像会修改 rpath 的链接路径.
我不确定 rpath 是否会从 DYLD_LIBRARY_PATH 搜索路径 (我猜不会), 以及在正式签名等场合下 DYLD_LIBRARY_PATH 是会被忽略的, 最好不要去依赖它.

有一个不修改 CMake 的思路: 在编译完 libaom 后, 手动执行 install_name_tool -id /usr/local/aom/3.6.0/lib/libaom.3.dylib /path/to/libaom.dylib

具体用法参见 man install_name_tool

手边暂时没有 mac 电脑, 没有办法实测有没有其他的坑.

macOS 上程序对系统依赖的判定与 Linux 不一样。

Linux 只保证了系统调用的 ABI 是稳定的，但它不提供任何用户态环境的保障，所以程序需要静态链接 C runtime 等依赖项。

但 macOS 只保证了 C runtime 和一大堆系统库的 API 是稳定的，它不保障系统调用是稳定的 (
https://developer.apple.com/forums/thread/706419 )，程序必须链接到 macOS 提供的 C runtime (以及 libSystem 之类) 的动态库上。

即使在 OS X 10.10 上，系统中也存在 /usr/lib/libz.1.dylib 和 /usr/lib/libSystem.B.dylib 。如果编译选项正确的话，Xcode 14 编译出来的程序能在 macOS 10.13 (甚至更早的系统) 上运行。

TL;DR:
如果只需要支持 Xcode 兼容的 deployment target (Xcode 14: macOS 10.13 或更新)，在满足 (1) 不链接到系统路径以外的动态库，(2) export MACOSX_DEPLOYMENT_TARGET=10.13 环境变量，或者提供了 -mmacosx-version-min=10.13 编译参数，(3) 编译 x86_64 和 ARM64 两份架构的代码，就应该能保证程序能在 macOS 10.13 以后的系统上运行。

如果要支持 OS X 10.9 或更老的系统，或者 i386/PPC 架构的话，就超出我的实践范围了。

首先清理图片文字的边缘, 用 likefont 识别, 识别的结果是 "方正 FW 童趣 POP 体".
然后去 Google 字体名字, 得知 "方正 FW 童趣 POP 体以 Fontworks 字体「ベビポップ EB 」为原型开发".
最后去 Fontworks 对比结果:

https://fontworks.co.jp/fontsearch/babypopstd-eb/?word=特典付きムビチケカード発売決定！