水木社区手机版
- 主题:后知后觉：zig的编译器有点厉害
- 通过自带glibc的头文件，外加伪造空的glibc的so，完美解决了随意指定glibc版本的问题。
工程上的一个小技巧，解决大问题。
然后cargo zigbuild让Rust也能受益于这个。
就是魔改的zig cc对gcc/clang的命令行参数的处理有些地方有点bug（或者说不一致）
--
FROM 123.122.126.* - 因为估计你不和glibc打交道
【 在 ooolinux 的大作中提到: 】
: 第一句话不太理解
--
FROM 123.122.126.* - Rust里通过cargo-zigbuild调用的zig cc
一、这个zig cc交叉编译只有Rust代码的工程，没啥问题
二、但是编译带有c/c++库的Rust工程，特别是有vcpkg库的，是个大坑，
已经折腾几天了，还是在github actions上，
如果不是AI搞，早就放弃了。
一是zig cc对某些命令行参数的格式要求，跟gcc/clang的不一样，尤其是-march这个。
二是zig cc是基于clang/llm的，跟gcc还是有差异，就要折腾编译c/c++库时的这些差异。
【 在 DoorWay 的大作中提到: 】
: 小技巧，维护数据库挺大，体力活。越来越大。
: 头痛医头，蛋疼揉蛋的直男风格。
: bun撤回了zig标签，要转rust。红点上在讨论对zig的影响。
--
FROM 123.122.126.* - 4楼讲了
【 在 harrycheng 的大作中提到: 】
: 不明觉厉！！！
: 请展开讲讲！！！
: 通过自带glibc的头文件，外加伪造空的glibc的so，完美解决了随意指定glibc版本的问题。
: ...................
--
FROM 123.122.126.* - zig的编译器就能当做c的编译器，毕竟是用clang/llvm深度魔改的。
而且自带glibc/musl的各种版本的头文件，如果编译参数不复杂（就是不要引入一堆第三方的c/c++库，特别是在-march里指定各种汇编加速参数的，否则可能是大坑），交叉编译不要太爽。
zig能直接import c的.h文件，不需要另写ffi binding。
【 在 chaobill 的大作中提到: 】
: 昨天看了， zig 相比 objc 对 c语言要友好多了
--
修改:z16166 FROM 123.122.126.*
FROM 123.122.126.* - 哈哈，感觉bun拥抱Rust是对的。虽然它搞的Rust实验性版本可能会被丢弃。
我只是说zig的编译器搞glibc的版本指定很方便，没说用zig语言写大工程很合适
c++里还有其他随便指定glibc版本的方法，比如cross-ng。
但我用的是Rust + vcpkg的混合，这个用zig cc就直接进大坑了，要写compiler wrapper script做桥接：
vcpkg/cmake/meson -> compiler wrapper script -> zig cc/cxx or gcc or ld or lld
compiler wrapper script夹在中间当小媳妇儿，非常痛苦
不过我新建分支搞的，不行就放弃
【 在 DoorWay 的大作中提到: 】
: 小技巧，维护数据库挺大，体力活。越来越大。
: 头痛医头，蛋疼揉蛋的直男风格。
: bun撤回了zig标签，要转rust。红点上在讨论对zig的影响。
--
修改:z16166 FROM 123.122.126.*
FROM 123.122.126.* - 哈哈，只差临门一脚了
荒野也可能是沙滩，转眼被拍死在沙滩上
【 在 DoorWay 的大作中提到: 】
: 不要放弃。你做的是有荣誉的事情，只有老鸟能做。
: 一想到这个事儿在业界知识/实践的边缘，是片无人之地，你走的路都是新路，你跳的坑都是新坑，里面脚印寥寥，甚至崭新没人踩过，——面对这片茫茫大地，那种油然而生的感觉，前不见古人后不见来者，那种体验，花几天时间，值了~
: 待到将来说古时，一般老鸟都讲，“你们知道吗，当年代码都是人一行一行敲……”。你会心一笑，想起当年在荒野，一人升起伟大的旗帜（flag），上面写着 -march=.....
--
FROM 123.122.126.* - 佳音就是弃坑后，换用“AlmaLinux 8容器 + 小红帽gcc-toolset-12”，又搞了几个小时完事了
zig cc/cxx编译带有c++库的工程，用compiler wrapper script也是难搞。
就用它搞搞纯血Rust工程好了。Rust + pure C的工程估计也能凑合。
【 在 DoorWay 的大作中提到: 】
: 成了回来更新帖子。静侯佳音！—— 遍踩群坑，穷举野径，战取天骄却，旌旗万里归。到时候告诉版友，-march后选项是啥 o_O
--
FROM 123.122.126.* - AI的语料太旧了
redhat的gcc toolset最新正式版已经是15了，它的语料里还是12
我之前的编译方案是AI按旧语料搞的（它可能不知道github最近两年有提供arm的原生runner），“容器外编译vcpkg，容器内再搞交叉编译”，到最后编译一次要四五十分钟。
然后才想试试cargo zigbuild。
【 在 DoorWay 的大作中提到: 】
: 一、 工程背景说明
: o 项目类型：混合语言工程。核心逻辑采用 Rust，但深度依赖 C/C++ 工业级库（如…）。
: o 包管理工具：使用 vcpkg 管理复杂的 C++ 依赖链，通过 CMake 或 Rust 的 cc crate 进行集成。
: ...................
--
FROM 123.122.126.* - AlmaLinux 8 + gcc toolset 15，也有少量坑，我还没完全趟平，也快了。
试试你的AI能总结哪些坑出来
【 在 DoorWay 的大作中提到: 】
: 红帽的魔改，在企业级生产环境的“向下兼容”这一件事上，确实比 zig cc 更强、更稳。 拼的是企业级人力物力。
: zig cc 的做法：尝试用一套自动化的符号解析脚本（把 glibc 源码的 .map 文件转成简化的符号桩），用逻辑和算法去“模拟”旧环境。
: 工程方案选择“向现实妥协”：
: ...................
--
FROM 123.122.126.*