环境
mcpp 2026.8.7.1，llvm 22.1.8，xim-x-glibc 2.39
宿主：Fedora，系统 glibc 2.43，Mesa（libGLX/libEGL 需 GLIBC_2.38+）
问题
mcpp 把每个二进制都链到自己的私有 glibc 2.39readelf -l 显示 PT_INTERP → $MCPP/xim-x-glibc/2.39/lib64/ld-linux-x86-64.so.2）。
这让产物没法直接分发：
目标机上没有 mcpp 安装 → 声明的解释器路径不存在 → 二进制根本无法启动。就算开发机上路径存在，直接运行也静默退出（code 255） ：glibc-2.39 的进程加载不了宿主 Mesa 的 GL 栈。（和 Linux 下 GLFW/OpenGL 程序运行时无法创建窗口:mcpp 自带 glibc(2.39)低于宿主 Mesa 要求(2.43),且 compat-x-glx-runtime 指向 32 位库 #352
常见的绕法是改用系统 loader 启动：
exec /lib64/ld-linux-x86-64.so.2 --library-path "/usr/lib64:..." /opt/app/bin
能跑起来，但带来一个新的、静默的坑：
这样启动后，内核把 /proc/self/exe 指向 loader（ld-linux-x86-64.so.2），而不是真实二进制。 所有"在可执行文件旁边找资源"的逻辑都静默失效：
GUI 框架的字体/资源解析（按 exe 目录找 assets/）→ 文字渲染空白；
应用内定位随包分发的引擎/辅助二进制同样失败；
/proc/self/cmdline 也是 loader 的 argv（混入 --library-path 等），按 argv 解析命令行的代码会拿到垃圾参数。
目前只能靠 launcher 里 cd 到安装目录、用 CWD 相对解析兜底——依赖 CWD，很脆弱。
期望
有没有官方支持的方式，让要分发的应用 链到系统 libc （不带私有 PT_INTERP），从而产物可直接执行、/proc/self/exe 行为正常？如果暂时不行，能否在文档里写明两点：(a) 私有 glibc 对分发的影响；(b) 系统 loader 包装后的 /proc/self/exe 陷阱？
相关：#352 （同根因、不同表现——#352 是 GL 窗口创建失败，这里是分发 + 资源解析）。
环境
问题
mcpp 把每个二进制都链到自己的私有 glibc 2.39
（
readelf -l显示PT_INTERP → $MCPP/xim-x-glibc/2.39/lib64/ld-linux-x86-64.so.2）。这让产物没法直接分发：
常见的绕法是改用系统 loader 启动：
能跑起来，但带来一个新的、静默的坑：
/proc/self/exe指向 loader（ld-linux-x86-64.so.2），而不是真实二进制。 所有"在可执行文件旁边找资源"的逻辑都静默失效：assets/）→ 文字渲染空白；/proc/self/cmdline也是 loader 的 argv（混入--library-path等），按 argv 解析命令行的代码会拿到垃圾参数。目前只能靠 launcher 里
cd到安装目录、用 CWD 相对解析兜底——依赖 CWD，很脆弱。期望
有没有官方支持的方式，让要分发的应用链到系统 libc（不带私有 PT_INTERP），从而产物可直接执行、
/proc/self/exe行为正常？如果暂时不行，能否在文档里写明两点：(a) 私有 glibc 对分发的影响；(b) 系统 loader 包装后的/proc/self/exe陷阱？相关：#352（同根因、不同表现——#352 是 GL 窗口创建失败，这里是分发 + 资源解析）。