search

Moroshima / zotero-deb

4 stars 0 forks source link

在 debian trixie/sid 上复现 firefox esr 60.9 构建 #4

Open Moroshima opened 1 year ago

Moroshima commented 1 year ago

在 debian trixie/sid 上复现 firefox esr 60.9 构建并将相关内容整理成文档

Moroshima commented 1 year ago

在 debian 13 trixie/sid 与 debian 12 bookworm 上进行构建均宣告失败，缺少旧版本 debian 所提供的 gtk 相关工具链软件包。在 debian 10 buster 与 ubuntu 18.04 上的构建因 rust cssparser 在构建中抛出致命性的语法错误使得 debian 构建失败，怀疑上游依赖或 rustc 版本变更导致编译失败（待验证）

Moroshima commented 1 year ago

在 debian 10 buster 与 ubuntu 18.04 上通过切换 rustc 版本至 1.32.0，qemu/kvm 虚拟机内存放大至 32 GiB 成功复现构建

Moroshima commented 1 year ago

rustc 以 gcc 为后端，gcc 版本会直接影响 rust 代码能否被正常编译，目前已知的是 debian 10 (buster) 为 gcc 8.3.0，ubuntu 18.04 则为 gcc 7.5.0。

Moroshima commented 1 year ago

以 gcc 9.5.0 为 rustc 编译后端编译失败，考虑到编译安装 gcc 7.x/8.x 对系统 gcc 环境会造成不可逆的严重破坏，个人更倾向于使用容器化环境进行 firefox 构建。同时考虑到 debian sid 源无 docker，且 docker 官方所提供的 debian stable 与 debian old stable 下 docker engine 等包为第三方源，可能无法符合 debian 社区要求，故个人觉得转向 systemd-nspawn 为更为合适的选择（相比古老的 lxc，systemd-nspawn 也更新，虽然其尚未在生产环境得到广泛应用）。

参考 InstallingGCC - GCC Wiki DebianAlternatives - Debian Wiki update-alternatives for gcc on Ubuntu

heroxbd commented 1 year ago

Moroshima @.***> writes:

rustc 以 gcc 为后端，gcc 版本会直接影响 rust 代码能否被正常编译，

rustc 的后端是 llvm ，不是 GCC 吧？

Moroshima commented 1 year ago

Moroshima @.> writes: Moroshima @.>写道： rustc 以 gcc 为后端，gcc 版本会直接影响 rust 代码能否被正常编译， rustc 的后端是 llvm ，不是 GCC 吧？

确实，是我谬误了，抱歉，被 ChatGPT 所给出的资料误导了，rustc 的后端是 llvm，21年 gcc 才提供了 rust 的后端支持。这里应该是语言间互操作或其他原因导致的（在编译 rust 模块时抛出的报错是 gamke 所抛出的定位到 c 源码中的报错）

Moroshima commented 1 year ago

Rust 会依赖 libc 和链接器 linker

参考 安装 Rust 环境 - Rust语言圣经(Rust Course)

Moroshima commented 1 year ago

相关编译环境比照及 debian trixie 报错信息 zotero-deb/firefox/environment.md at 8ef5368d2fa615efa9436b7a6cf0f2fa5c3d43d2 · Moroshima/zotero-deb

Moroshima commented 1 year ago

通过 Claude-2-100k 的提取分析，其给出的总结中提到了 structs.rs 是“bindgen”自动生成的，而 bindgen 的用途确实是 “automatically generates Rust FFI bindings to C (and some C++) libraries”，因此我们可以先排除 llvm，优先将 debian sid 上的 gcc 降级以观察 firefox 60.9 esr 是否能正常编译。

参考 rust-lang/rust-bindgen: Automatically generates Rust FFI bindings to C (and some C++) libraries.

Moroshima commented 1 year ago

“没有什么比编译 gcc 更痛苦，如果有，那就是编译内核。”

Moroshima commented 1 year ago

感谢 our gentoo friends 为 gcc 8.3.0 所准备的 patch 文件

Moroshima commented 1 year ago

将 gcc 降级为 8.3.0 后依然存在相同的报错，接下来优先考虑降级系统核心动态链接库 libstdc++

Moroshima commented 1 year ago

firefox 社区频道提到我不仅要将 gcc 降级，clang 可能也是必要的

图片

Moroshima commented 1 year ago

我将会暂时性终止对 debian trixie/sid 以及 debian bookworm 下构建的尝试并先对 gcc 及 firefox 在 debian bookworm/trixie 上的构建脚本及相关资料进行整理上传

Moroshima commented 1 year ago

通过 Claude-2-100k 的提取分析，其给出的总结中提到了 structs.rs 是“bindgen”自动生成的，而 bindgen 的用途确实是 “automatically generates Rust FFI bindings to C (and some C++) libraries”，因此我们可以先排除 llvm，优先将 debian sid 上的 gcc 降级以观察 firefox 60.9 esr 是否能正常编译。

参考 rust-lang/rust-bindgen: Automatically generates Rust FFI bindings to C (and some C++) libraries.

事实证明，对于一个包管理器是使用 C++ 编写的操作系统而言，切换 libstdc++ 版本并不是什么聪明的行为。超级牛力和 ccache 一类依赖较新（6.0.32+） libstdc++.so.6 的软件全部失能

apt: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by apt)
apt: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /lib/x86_64-linux-gnu/libapt-private.so.0.0)
apt: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libapt-private.so.0.0)
apt: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /lib/x86_64-linux-gnu/libapt-pkg.so.6.0)
apt: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libapt-pkg.so.6.0)
apt: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libapt-pkg.so.6.0)
Moroshima commented 1 year ago

通过卸载 clang 重做编译证实 FFI 确实只使用到了 gcc，我已经感到无从下手了

Moroshima commented 1 year ago

暂时去 mozilla chat 提问了下，希望并祈祷有核心开发者能解答我的困惑吧（

Moroshima commented 1 year ago

怀疑点+1 /lib/x86_64-linux-gnu/libc.so.6

Moroshima commented 1 year ago

通过卸载 clang 重做编译证实 FFI 确实只使用到了 gcc，我已经感到无从下手了

mozilla 开发者给了我一点启发，我此前并未注意 bindgen 转换代码具体依赖 lib，想当然的以为其与 rustc 一致，将会使用 gcc 相关的 lib 来进行代码转换。但 mozilla 的开发者提到 bindgen 依赖 libclang，我重新通读了一遍 bindgen 的 README，发现其并非 Rust FFI 这一 interface 的实现，而是一套独立的代码生成工具，并且其强依赖 libclang，并有相关文档。我此前的怀疑与探究方向被否定，我将会再尝试在纯净的 debian trixie/sid 环境下进行构建。

Moroshima commented 1 year ago

但依旧存在一点疑问，old c code -> old rust-bindgen & new libclang -> ? rust code 理论上不使用新 clang 所支持的新语法的旧 C/C++ 代码在经过旧版本 rust-bindgen 处理后不应产生任何问题，我唯一能想到的解释是 rust-bindgen 与 new libclang 存在不兼容造成代码转换产生未知错误

Moroshima commented 1 year ago

此前我在 debian trixie/sid 上构建旧版本 llvm/clang （llvm 7.0）的尝试是失败的，需要再度 debug

heroxbd commented 1 year ago

CentOS 7 与 Debian Sid 环境的所有 toolchain 的版本区别都有哪些？

CentOS 7 上使用的也是 rust 1.32 吗？

Moroshima commented 1 year ago

CentOS 7 与 Debian Sid 环境的所有 toolchain 的版本区别都有哪些？

CentOS 7 上使用的也是 rust 1.32 吗？

目前的 toolchain 差异整理于此 https://github.com/Moroshima/zotero-deb/tree/master/firefox#environment ，可复现于 debian 10 buster 以及 ubuntu 18 bionic，centos 7 上的构建是失败的，是我的失误致使我在确认编译情况的时候错误的认为其可以在 centos 7 上进行构建，后续整理资料过程中我已纠正了该谬误并在 debian 10 & ubuntu 18 上复现了构建。

Moroshima commented 1 year ago

一条条命令行里敲命令倒是能把环境搭起来，写成脚本跑一半寄了都不知道问题出在哪个步骤（

heroxbd commented 1 year ago

Moroshima @.***> writes:

一条条命令行里敲命令倒是能把环境搭起来，写成脚本跑一半寄了都不知道问题出在哪个步骤（

好好学习写脚本。 加上 set -e

Moroshima commented 1 year ago

在全新系统上的构建在使用gcc-12的情况下并未出现rust-bingen的报错，rust代码编译已经到了最终编译Release的阶段，但此前出现的纯C代码编译存在的问题似乎导致了最终编译的失败

 0:02.22 In file included from /home/moroshima/firefox-60.9.0/ipc/chromium/src/third_party/libevent/evutil_rand.c:134,
 0:02.22                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/ipc/chromium/src/third_party/Unified_c_src_third_party0.c:128:
 0:02.22 /home/moroshima/firefox-60.9.0/ipc/chromium/src/third_party/libevent/./arc4random.c:498:1: error: static declaration of ‘arc4random_buf’ follows non-static declaration
 0:02.22   498 | arc4random_buf(void *buf_, size_t n)
 0:02.22       | ^~~~~~~~~~~~~~

在尝试回退到gcc-8.3.0的过程中编译出现了问题，此问题是此前所未遇到的

图片

Moroshima commented 1 year ago

Moroshima @.***> writes: 一条条命令行里敲命令倒是能把环境搭起来，写成脚本跑一半寄了都不知道问题出在哪个步骤（ 好好学习写脚本。 加上 set -e

收到

Moroshima commented 1 year ago

在全新系统上的构建在使用gcc-12的情况下并未出现rust-bingen的报错，rust代码编译已经到了最终编译Release的阶段，但此前出现的纯C代码编译存在的问题似乎导致了最终编译的失败

 0:02.22 In file included from /home/moroshima/firefox-60.9.0/ipc/chromium/src/third_party/libevent/evutil_rand.c:134,
 0:02.22                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/ipc/chromium/src/third_party/Unified_c_src_third_party0.c:128:
 0:02.22 /home/moroshima/firefox-60.9.0/ipc/chromium/src/third_party/libevent/./arc4random.c:498:1: error: static declaration of ‘arc4random_buf’ follows non-static declaration
 0:02.22   498 | arc4random_buf(void *buf_, size_t n)
 0:02.22       | ^~~~~~~~~~~~~~

在尝试回退到gcc-8.3.0的过程中编译出现了问题，此问题是此前所未遇到的

图片

重新起了台干净的虚拟机做gcc编译成功了，gcc编译失败应该是我移除了gcc尝试直接使用clang进行编译导致的

Moroshima commented 1 year ago

重新更换gcc后编译

 4:59.08 libchromium_atomics.a.desc
 4:59.16 In file included from /home/moroshima/firefox-60.9.0/ipc/chromium/src/third_party/libevent/evutil_rand.c:134,
 4:59.16                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/ipc/chromium/src/third_party/Unified_c_src_third_party0.c:128:
 4:59.16 /home/moroshima/firefox-60.9.0/ipc/chromium/src/third_party/libevent/./arc4random.c:499:1: 错误：对‘arc4random_buf’的静态声明出现在非静态声明之后
 4:59.16  {
 4:59.16  ^
 4:59.16 In file included from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/system_wrappers/stdlib.h:3,
 4:59.16                  from /home/moroshima/firefox-60.9.0/ipc/chromium/src/third_party/libevent/buffer.c:75,
 4:59.16                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/ipc/chromium/src/third_party/Unified_c_src_third_party0.c:2:
 4:59.16 /usr/include/stdlib.h:542:13: 附注：‘arc4random_buf’的上一个声明在此
 4:59.16  extern void arc4random_buf (void *__buf, size_t __size)
 4:59.16              ^~~~~~~~~~~~~~
 4:59.19 libnksctp_s.a.desc
 4:59.27 gmake[4]: *** [/home/moroshima/firefox-60.9.0/config/rules.mk:782：Unified_c_src_third_party0.o] 错误 1
 4:59.27 gmake[3]: *** [/home/moroshima/firefox-60.9.0/config/recurse.mk:73：ipc/chromium/src/third_party/target] 错误 2
 4:59.27 gmake[3]: *** 正在等待未完成的任务....

无论如何都是之前出现过但我没在意的那部分报错，在之前的编译过程中其一般与rust-bindgen的报错一起出现，但是重新起的空环境从头配置并编译并未出现rust-bindgen的报错，而仅出现了arc4random_buf相关的报错

Moroshima commented 1 year ago

对环境作出的改动主要是在mach bootstrap前安装了rustup&rustc，并一开始即安装1.32.0版本；其次完整运行了bootstrap并将patch掉的过时python包安装了对应的python3版本（但这些py3包感觉对编译影响不大）

Moroshima commented 1 year ago

就编译全流程来看，我们几乎接近了成功，在release编译完成后firefox几乎可以说完成了99%的编译工作。但显然arc4random_buf卡住了编译流程

图片

Moroshima commented 1 year ago

diff了下buster和trixie（刚升级了下）的stdlib，应该是其中改动所致，当时相关arc4random实现可能并未被合入stdlib，下面先对其进行回滚尝试

Moroshima commented 1 year ago 
 3:29.27 In file included from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/xpcom/base/Unified_cpp_xpcom_base2.cpp:47:
 3:29.27 /home/moroshima/firefox-60.9.0/xpcom/base/nsUUIDGenerator.cpp: 在成员函数‘virtual nsresult nsUUIDGenerator::GenerateUUIDInPlace(nsID*)’中:
 3:29.27 /home/moroshima/firefox-60.9.0/xpcom/base/nsUUIDGenerator.cpp:125:3: 错误：‘arc4random_buf’在此作用域中尚未声明
 3:29.28    arc4random_buf(aId, sizeof(nsID));
 3:29.28    ^~~~~~~~~~~~~~
 3:29.31 /home/moroshima/firefox-60.9.0/xpcom/base/nsUUIDGenerator.cpp:125:3: 附注：suggested alternative: ‘g_random_int’
 3:29.31    arc4random_buf(aId, sizeof(nsID));
 3:29.31    ^~~~~~~~~~~~~~
 3:29.31    g_random_int

疑惑

heroxbd commented 1 year ago

Moroshima @.***> writes:

diff了下buster和trixie（刚升级了下）的stdlib，应该是其中改动所至，当时相关arc4random实现可能并未被合入stdlib

你说的 stdlib 是指 glibc 的 stdlib.h 吧？

Moroshima commented 1 year ago

Moroshima @.***> writes: diff了下buster和trixie（刚升级了下）的stdlib，应该是其中改动所至，当时相关arc4random实现可能并未被合入stdlib 你说的 stdlib 是指 glibc 的 stdlib.h 吧？

是的

Moroshima commented 1 year ago

重新观察审视了debian buster下的构建流程，并未出现相同的arc4random的error，说明arc4random.c很有可能与sUUIDGenerator.cpp处于同一命名空间之中，但从实际文件而言其两者分属xpcom与ipc/chromium两个模块，究竟其为何会存在未定义的问题，同时为何debian buster下就不存在该问题值得分析，即进一步分析源码组织逻辑

感觉编译环境的debug就和炼丹一样，你往里面加点啥，加东西的先后顺序都有可能影响编译过程，特别是firefox这种大型的工具极多的项目

Moroshima commented 1 year ago

看了下两个（ipc/chrouium与xpcom）两部分的编译逻辑，两者相互独立，显然不会共享命名空间。在全新的虚拟机中进行了尝试，与昨天情况一致，仍然报错arc4random重复定义

Moroshima commented 1 year ago

https://www.bitbenderforums.com/forums/showthread.php?90498-I-just-noticed-new-Firefox-released-today&p=584163

heroxbd commented 1 year ago

Moroshima @.***> writes:

https://www.bitbenderforums.com/forums/showthread.php?90498-I-just-noticed-new-Firefox-released-today&p=584163

看来社区对 Firefox 的意见很大

Moroshima commented 1 year ago

备忘笔记

  1. 在编译 python2 前至少需要 zlib1g-dev 与 libssl-dev，前者在 bootstrap 时被引用，后者在构建前期环境准备阶段用于处理 http 句柄（https）
  2. rustup 虽然 bootstrap 过程中 firefox 会安装，但是安装的是最新版 rustc (stable)，建议在此之前手动介入安装 rustc 1.32.0
  3. python2 编译环境需求至少 xz-utils （解压），gcc （编译），make （构建）
  4. 正式编译开始前请务必 patch 掉几个 debian 环境下 python2 包的安装：https://github.com/Moroshima/zotero-deb/blob/master/firefox/bootstrap-debian-bookworm.patch
  5. 目前针对 arc4random 尝试了替换 stdlib.h 的做法，我希冀于 firefox 编译前阶段对库文件中 arc4random 支持的检查并期望它自动调整编译逻辑，但显然失败了。

同时如前所述，旧的库文件会导致部分代码认为 arc4random 没定义，新的库文件则会导致 arc4random 被重复定义。但我们在 debian 10 buster 上能成功复现，说明库文件很可能不是问题的关键所在，但在编译过程中我并未捕获到其他报错信息，目前的进度难以推进，我将会将问题整理后再度向 mozilla 社区寻求帮助，但就以往几次询问的经验而言，我对 mozilla 社区能对这样一个旧版本源码所能提供的技术支持与帮助并不抱有太大期望。

参考 https://superuser.com/questions/801159/cannot-decompress-tar-xz-file-getting-xz-cannot-exec-no-such-file-or-direct https://stackoverflow.com/questions/6169522/no-module-named-zlib https://stackoverflow.com/questions/20688034/importerror-cannot-import-name-httpshandler-using-pip https://firefox-source-docs.mozilla.org/setup/linux_build.html

Moroshima commented 1 year ago

图片

同样的报错稳定复现于我手上的所有debian 12 环境 （图为 debian 12 bookworm on wsl2）

heroxbd commented 1 year ago

arc4random 的 header 定义都找到了吗？

Moroshima commented 1 year ago

arc4random 的 header 定义都找到了吗？

抱歉，还没有，昨天晚上会后找了下 libevent 似乎是直接定义 arc4random.c 然后引用使用 arc4random 相关方法的，今天因为一些事情没来得及继续这部分工作

Moroshima commented 1 year ago 
PLATFORM_DEPENDENT_SRC = \
    arc4random.c \
    epoll_sub.c

arc4random.c 作为依赖被构建（Makefile.am）

以 ARC4RANDOM_EXPORT 的方式导出各方法（但这是如何实现的，只依靠一行空宏的定义就导出函数，理论上空宏会被解释器直接替换成空白，这有待学习）

#ifndef ARC4RANDOM_EXPORT
#define ARC4RANDOM_EXPORT
#endif
ARC4RANDOM_EXPORT void
arc4random_buf(void *buf_, size_t n)
{
    unsigned char *buf = buf_;
    ARC4_LOCK_();
    arc4_stir_if_needed();
    while (n--) {
        if (--arc4_count <= 0)
            arc4_stir();
        buf[n] = arc4_getbyte();
    }
    ARC4_UNLOCK_();
}
heroxbd commented 1 year ago

就一个

uint32_t arc4random(void);

的定义吧？你说新的 glibc 也有 arc4random 导致了重复定义，具体如何用最少 的代码复现？

Moroshima commented 1 year ago

就一个 uint32_t arc4random(void); 的定义吧？你说新的 glibc 也有 arc4random 导致了重复定义，具体如何用最少 的代码复现？

老师您所提到的就一个的定义应该是 stdlib 中所给出的？

最少复现只需要直接 make libevent 即可，mozilla 描述这份 libevent copy 为 This is a clean copy of libevent-2.1.8-stable with the following modifications. （README.mozilla）

Moroshima commented 1 year ago 
sudo apt install libevent-2.1-7 libevent-core-2.1-7 libevent-extra-2.1-7 libevent-dev
MOZ_SYSTEM_LIBEVENT=1 ./mach build

6 成功使用系统 libevent 绕过了该部分编译

Moroshima commented 1 year ago

新的 bug，按照 libevent 的经验，可以定性为大概率是由 glibc 支持变动导致的

 0:02.93 /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/include/mozilla/PlatformMutex.h:31:26: note: use unary ‘+’ which decays operands to pointers or ‘&‘component_ref’ not supported by dump_decl<declaration error>[0] == &‘component_ref’ not supported by dump_decl<declaration error>[0]’ to compare the addresses
 0:02.93 /home/moroshima/firefox-60.9.0/tools/profiler/core/platform.h: At global scope:
 0:02.93 /home/moroshima/firefox-60.9.0/tools/profiler/core/platform.h:50:21: error: ‘pid_t gettid()’ was declared ‘extern’ and later ‘static’ [-fpermissive]
 0:02.93    50 | static inline pid_t gettid() { return (pid_t)syscall(SYS_gettid); }
 0:02.93       |                     ^~~~~~
 0:02.93 In file included from /usr/include/unistd.h:1218,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/system_wrappers/unistd.h:3,
 0:02.93                  from /usr/include/x86_64-linux-gnu/bits/sigstksz.h:24,
 0:02.93                  from /usr/include/signal.h:328,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/system_wrappers/signal.h:3,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/include/mozilla/Assertions.h:64,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/include/nsDebug.h:14,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/include/nsCharTraits.h:22,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/include/nsStringIterator.h:1 ,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/include/nsAString.h:12,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/include/nsString.h:14,
 0:02.93                  from /home/moroshima/firefox-60.9.0/obj-x86_64-pc-linux-gnu/dist/include/shared-libraries.h:2 ,
 0:02.93                  from /home/moroshima/firefox-60.9.0/tools/profiler/core/shared-libraries-linux.cc:7:
Moroshima commented 1 year ago

https://bugzilla.mozilla.org/show_bug.cgi?id=1533969

mozilla 的 bug report 在 firefox 67 提到了该问题，应应用该部分代码改动 patch 并重新尝试构建

Moroshima commented 1 year ago 
moroshima@Haruna:~/firefox-60.9.0$ rg "pid_t gettid()" ./
./tools/profiler/core/platform.h
50:static inline pid_t gettid() { return (pid_t)syscall(SYS_gettid); }
54:static inline pid_t gettid() { return (pid_t)syscall(SYS_thread_selfid); }

./mozglue/build/BionicGlue.cpp
110:  extern pid_t gettid(void);

patch ./tools/profiler/core/platform.h 即可

所应用的 patch 为 https://hg.mozilla.org/integration/autoland/rev/7b85bf9c5210