当前位置： 文江博客 话题详情

使用标志构建glibc _file_offset_bits = 64和_time_bits = 64失败

发布于 2025-02-11 11:56:02 字数 334 浏览 1 评论 0 原文

我想做的是在Y2038问题上为GLIBC提供解决方案。 我在Ubuntu 18.04 VM中使用BuildRoot 2022.02.2进行交叉编译，用于32位ARM CPU。 我读到添加额外的标志_file_offset_bits = 64和_time_bits = 64应该这样做，但是我会得到这样的构建错误

/tmp/cclzlgs6.s：soundationbler messages： /tmp/cclzlgs6.s：138：错误：符号`_____igtimedWait64'is 已经定义了

对2.34中Y2038发行的支持，还是在进行工作？ 还是我做错了什么，例如错过一些旗帜？

谢谢你， 加泰罗尼亚

原文

What I want to do is have a fix in glibc for the Y2038 issue.
I am using buildroot 2022.02.2 in my Ubuntu 18.04 VM to cross-compile for an 32-bit ARM CPU.
I read that adding extra flags _FILE_OFFSET_BITS=64 and _TIME_BITS=64 should do that, but I get build error like this

/tmp/cclzLgs6.s: Assembler messages:
/tmp/cclzLgs6.s:138: Error: symbol `__sigtimedwait64' is
already defined

Is the support for Y2038 issue available in 2.34, or is it work-in-progress ?
Or maybe I'm doing something wrong, like missing some flags ?

thank you,
Catalin

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（1）

知你几分 2025-02-18 11:56:03

您可以执行以下操作以获取Y2038安全的BuildRoot 32位ARM系统：

  1. 在 https://developer.arm.com/tools-and-software/open-source-source-software/developer-teveloper-tevelicer-tools/gnu-tools/gnu-toolchain/downloads 。版本11.2-2022.02由GCC 11.2和GLIBC 2.34组成。 （_time_bits = 64选项是在glibc 2.34中引入的。）
  2. 使用具有版本＆gt; = 5.1的Linux内核。 https://sourceware.orcceware.orgceware.org/pipermc/pipermail/pipermc-pipermail/libc-202222212222222 8月/129718.html 说5.1是64位时间的全部支持所必需的。
  3. 在，但随后被恢复为 https：// github.com/buildroot/buildroot/commit/dd170f0cbad729dba4193b2b2b20e3de0a7010d485 由于未能构建一些包装。您仍然应该做的是根据第一个补丁添加_time_bits = 64。
  4. 您可能会因某些不确定_file_offset_bits（尤其是Zlib套件）以及将Zlib嵌入Zlib嵌入代码中的软件包而获得构建错误。这里的一个简单修复程序是在_file_offset_bits不确定时，将这些软件包中的代码修改为unef _time_bits。在所有情况下，这似乎都起作用，因为受影响的编译单元无论如何都没有使用任何时间功能。

例如，将此补丁放在buildroot/potpack/libzlib/：

--- a/gzguts.h
+++ b/gzguts.h
@@ -9,6 +9,7 @@
 #  endif
 #  ifdef _FILE_OFFSET_BITS
 #    undef _FILE_OFFSET_BITS
+#    undef _TIME_BITS
 #  endif
 #endif

这是必需的，因为在glibc标头中有一个断言，当_time_bits为64时，错误出现

错误

了 Zlib的新版本1.3版本包括上面的补丁（）。

我注意到的一件事是，可以从其网站下载的预编译的手臂工具链与内核v4.20.13的Linux内核标头捆绑在一起。这些旧标头与_time_bits = 64不兼容，在某些情况下，例如使用so_timestamp/scm_timestamp，因为这些旧标头定义了不正确的（旧的）整数。我通过看到损坏的时间戳来运行BTMON记录器时注意到了这一点。我决定使用针对我实际使用的Linux内核版本的更新的Linux内核标头构建自己的工具链。

幸运的是，由于自动构建脚本以及ARM的工具链释放提供的说明，可以通过单击相关下载部分底部的“释放注释”链接来找到，从头开始构建工具链。这些说明是在“使用Linaro的ABE来源构建Linux托管工具链”下找到的。该示例用于 Arm-gnu-toolchain-aarch64-none-felf ，但相应的说明适用于 arm-gnu-gnu-toolchain-toolchain-arm-arm-arm-none-linux-linux-gnueaeabihf 。

In the downloaded

用新的工具链替换预编译的工具链后，BTMON现在显示正确的时间戳。

再次更新：

BuildRoot终于正式添加了_time_bits = 64标志，您可以轻松地通过配置选项 br2_time_bits_64 。请注意，如上所述，您仍然应该确保拥有使用适当的Linux标头构建的工具链。

You can do the following to get a Y2038 safe buildroot 32-bit ARM system:

  1. Use the pre-compiled ARM toolchain at https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/downloads. Version 11.2-2022.02 consists of GCC 11.2 and glibc 2.34. (The _TIME_BITS=64 option was introduced in glibc 2.34.)
  2. Use a Linux kernel with version >= 5.1. https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html says 5.1 is required for full support for 64-bit time.
  3. There was an attempt to enable system-wide _TIME_BITS=64 in buildroot in https://github.com/buildroot/buildroot/commit/6e33e5908086a511294296f317f6e6f86fa84b1d, but was later reverted in https://github.com/buildroot/buildroot/commit/dd170f0cbad729dba4193b2b20e3de0a7010d485 due to failure to build some packages. What you should still do is to add _TIME_BITS=64 according to the first patch.
  4. You might get build errors for some packages that undefine _FILE_OFFSET_BITS, in particular the zlib packages, and packages that embed zlib in their code. A simple fix here is to modify the code in these packages to also undef _TIME_BITS whenever _FILE_OFFSET_BITS gets undefined. This seems to work in all cases I have looked at since the affected compilation units do not make use of any time functions anyway.

For example, put this patch as 0002-time-bits.patch in buildroot/package/libzlib/:

--- a/gzguts.h
+++ b/gzguts.h
@@ -9,6 +9,7 @@
 #  endif
 #  ifdef _FILE_OFFSET_BITS
 #    undef _FILE_OFFSET_BITS
+#    undef _TIME_BITS
 #  endif
 #endif

This is required because there is an assertion in the glibc headers that error out when _TIME_BITS is 64 but _FILE_OFFSET_BITS is not 64.

UPDATE:

The newly released version 1.3 of zlib includes the patch above (https://github.com/madler/zlib/commit/a566e156b3fa07b566ddbf6801b517a9dba04fa3).

One thing I noticed is that the pre-compiled ARM toolchain that can be downloaded from their website is bundled with Linux Kernel headers from kernel v4.20.13. These old headers are incompatible with _TIME_BITS=64 in some cases, for example the usage of SO_TIMESTAMP/SCM_TIMESTAMP, since these old headers define the incorrect (old) integers. I noticed this while running the btmon logger by seeing corrupt timestamps. I decided to build my own toolchain using updated Linux Kernel headers targeting the Linux Kernel version I'm actually using.

Fortunately, building the toolchain from scratch is relatively straightforward thanks to the automatic build script and the instructions supplied by every release of ARM's toolchain which can be found by clicking the "Release Note" link at the bottom of the relevant download section. The instructions are found under "Building Linux hosted toolchain from sources using Linaro's ABE". The example is for arm-gnu-toolchain-aarch64-none-elf but the corresponding instructions apply for arm-gnu-toolchain-arm-none-linux-gnueabihf as well.

In the downloaded manifest file, I changed linux_revision=v4.20.13 to linux_revision=v6.3 (which is my target kernel version) and removed the linux_md5sum line (I was too lazy to find out the checksum). For some very strange reason, the gcc_stage2_flags are apparently different in the example manifest compared to the ones used in pre-compiled released binaries. Notably, libatomic is not included due to --disable-libatomic in the example manifest file. But libatomic is required by many buildroot packages, e.g. ones that need to perform atomic operations on objects larger than 8 bytes, or packages that just happen to link to libatomic.so anyway. To better align with the binary release, I removed --disable-libatomic --without-cloog --without-isl --disable-libgomp --disable-libquadmath from gcc_stage2_flags (but did not touch gcc_stage1_flags).

After replacing the pre-compiled toolchain with this new one, btmon now shows the correct timestamps.

UPDATE AGAIN:

Buildroot has finally officially added the _TIME_BITS=64 flag which you can easily enable through the config option BR2_TIME_BITS_64. Note that you should still make sure you have a toolchain built with the appropriate Linux headers, as mentioned above.

回复 原文
~没有更多了~

关于作者

骄傲

暂无简介

文章
评论
27 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

李珊平

文章 0 评论 0

Quxin

文章 0 评论 0

范无咎

文章 0 评论 0

github_ZOJ2N8YxBm

文章 0 评论 0

若言

文章 0 评论 0

南…巷孤猫

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文