Repository navigation
Conversation
现有 agent2api-server 只有 glibc 动态链接产物,在 Alpine / distroless /
Android(Magisk 模块)这类没有 /lib/ld-linux-* 的环境里连解释器都找不到;
glibc 解析器又硬读 /etc/resolv.conf,而这些环境里那个文件要么不存在、
要么不归本服务管。
改法:新增 .github/workflows/build-musl-server.yml,用 cargo-zigbuild 出
aarch64 / x86_64 的 musl 静态产物(单文件、无 PT_INTERP,约 14MB),
产物命名沿用现有规则 agent2api-server-linux-{arm64,amd64}-musl.tar.gz(.sha256),
容器内一键更新那边把 update_asset 指过来即可。
这份工作流刻意只允许 workflow_dispatch 手动触发:本仓库的构建已整体搬到
构建仓库,推 tag 只跑派发 job,不应该因为加了这个文件就变成「推 tag 开
构建机」。等配方验证稳定后直接搬去构建仓库即可。
docs/build-musl-server.md 记了为什么值得出这个产物、CI 与本机两种编法、
验证命令,以及 Windows 上交叉编译的两个坑(mingw 工具链、zig 转发 shim)。
仓库 .cargo/config.toml 里 target-dir 已指到仓库根的 target/,工作流却按 src-tauri/target/<triple>/release 去找二进制 —— 第一次真跑就挂在「自检」那一步。 改成从 cargo metadata 读 target_directory,顺带在找不到文件时给出明确报错。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
这个 PR 做什么
给服务端补一份 musl 静态构建配方:
.github/workflows/build-musl-server.yml—— 用cargo-zigbuild出aarch64/x86_64的 musl 静态包;docs/build-musl-server.md—— 为什么值得出、CI 与本机两种编法、验证命令、Windows 交叉编译的坑。产物命名沿用现有规则,方便被现有安装/更新脚本直接消费:
为什么要这个变体
现有
agent2api-server-linux-arm64.tar.gz是 glibc 动态链接,下面三类环境会卡住:no such file or directory,但file明明显示是合法 ELF/lib/ld-linux-aarch64.so.1,内核找不到 PT_INTERP 指的解释器dns error/etc/resolv.conf,Android 上那个文件不存在或不归本服务管GLIBC_2.xx not foundmusl 静态构建一次消掉这三个:无 PT_INTERP、不需要 loader、不链接宿主 libc、单文件。
为什么只在
workflow_dispatch上跑本仓库的构建已整体搬到构建仓库,推 tag 只跑那个十几秒的派发 job —— 这条边界我不想碰。所以这份工作流不挂 tag 触发,只有手动点:
等配方在真实发版节奏里验证过,直接把文件搬到
Agent2Builder/agent2api-releases、改成跟repository_dispatch一起跑就行,源仓库这边删掉即可。实测数据(本机交叉编译 + 真机跑过)
在 Windows 上用
stable-x86_64-pc-windows-gnu+aarch64-unknown-linux-musl+ zig 0.17(zig 当 C 交叉编译器)编出:装进一个 Android 的 Magisk 模块里跑通了:进程
maps里没有任何.so,cmdline直接就是二进制路径(不经过ld.so),/health、/v1/models、/v1/chat/completions全部 200。顺带一个有意思的对照:某台 Android 的内核会拦 AAAA 查询(
sendto返回EPERM),glibc 的getaddrinfo(AF_UNSPEC)因此整次EAI_AGAIN全挂;musl 把 A 与 AAAA 塞进同一个 UDP 包发出,不受影响,AF_UNSPEC正常返回。这算是静态 musl 在恶劣网络环境下的一个意外好处。已知差异(写进文档了,这里重复一遍)
/etc/nsswitch.conf;musl 解析器直接读/etc/resolv.conf,hosts走内置表。本项目只用getaddrinfo做 A/AAAA,不受影响。/etc/resolv.conf路径是编译期常量。将来若真要支持「解析器配置路径可配」,建议单独开 PR 加AGENT2API_RESOLV_CONF,本 PR 不碰代码逻辑。验证方式
CI 里同样的断言写进了「自检」那一步,产物一旦是动态链接会直接失败,不会静默发出去。
🤖 本条回复由 AI Agent 生成