MacOS 12.7.2中DYLD_LIBRARY_PATH无法在Shell脚本中继承的问题排查

问题背景 #

在macOS 12.7.2系统中，我有一个通过dlopen加载dylib的程序，必须设置DYLD_LIBRARY_PATH环境变量才能让程序找到依赖库。但将相关命令放入Shell脚本执行时却失败了——DYLD_LIBRARY_PATH无法被脚本继承，其他环境变量则能正常传递。

测试示例 #

~/felix-lang.github.io>cat xx.sh
echo $DYLD_LIBRARY_PATH
~/felix-lang.github.io>sh xx.sh

~/felix-lang.github.io>echo $DYLD_LIBRARY_PATH
/Users/skaller/felix/build/release/host/lib/rtl

由于dlopen使用的是库的相对名称，必须依赖系统的路径搜索功能定位库，因此这个继承问题直接导致程序无法运行。

临时解决方案 #

我找到了一个临时可行的办法：

export XX=$DYLD_LIBRARY_PATH
~/felix-lang.github.io>cat xx.sh
export DYLD_LIBRARY_PATH=$XX
echo $DYLD_LIBRARY_PATH

这个方案能让程序正常运行，但理论上完全不需要多此一举。

补充测试数据 #

感谢@Charles Duffy提供的额外测试结果：
在当前终端中查看变量声明：

~/felix-lang.github.io>declare -p DYLD_LIBRARY_PATH
declare -x DYLD_LIBRARY_PATH="/Users/skaller/felix/build/release/host/lib/rtl"

但用printenv却无法查到这个变量：

~/felix-lang.github.io>printenv | grep LIBRARY
CAML_LD_LIBRARY_PATH=/Users/skaller/.opam/5.1.1/lib/stublibs:/Users/skaller/.opam/5.1.1/lib/ocaml/stublibs:/Users/skaller/.opam/5.1.1/lib/ocaml
LD_LIBRARY_PATH=/Users/skaller/felix/build/release/host/lib/rtl

即使手动重新导出变量，它依然无法被子Shell继承：

~/felix-lang.github.io>export DYLD_LIBRARY_PATH="HelloWorld"
~/felix-lang.github.io>sh
~/felix-lang.github.io>echo $DYLD_LIBRARY_PATH

~/felix-lang.github.io>

dyld手册说明 #

手册中明确标注DYLD_LIBRARY_PATH是合法的环境变量：

In general, dyld does not search for dylibs. Dylibs are specified via a full path, either as a static dependent dylib in a mach-o file, or as a path passed to dlopen() , But during development the env vars DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH can be used to override the specified path and look for the leaf framework/dylib name in the specified directories.

（翻译：通常情况下，dyld不会搜索dylib库。Dylib库通过完整路径指定——要么是Mach-O文件中的静态依赖库路径，要么是传递给dlopen()的路径。但在开发阶段，可以使用环境变量DYLD_LIBRARY_PATH和DYLD_FRAMEWORK_PATH覆盖指定路径，在指定目录中查找框架/dylib的文件名。）

问题原因分析 #

这是macOS的安全机制限制：为了防止恶意库劫持系统进程，Apple在系统中对DYLD_*系列环境变量做了特殊处理——当通过子Shell（比如执行sh/bash脚本）启动进程时，系统会主动清除这些变量，不让它们被子进程继承。

即使你在当前Shell中导出了DYLD_LIBRARY_PATH，当启动新的Shell进程时，系统的dyld加载器会拦截并移除这个变量，导致子进程无法获取到它。而declare -p能看到变量，是因为这个命令读取的是当前Shell的内部变量表，而非实际传递给子进程的环境变量集合；printenv看不到则是因为它读取的是实际的环境变量，此时DYLD_LIBRARY_PATH已经被系统过滤掉了。

额外说明 #

我之所以依赖dlopen的路径搜索而非传入绝对路径，是因为程序本身不知道插件的具体位置，且希望允许替换插件（即主动支持所谓的“库劫持”场景），不想自己编写路径搜索逻辑。

内容的提问来源于stack exchange，提问作者Yttrill