• 状态
  • 已锁定 已锁定
  • 回复 6 回复
  • 订户 0 订户
  • 视图 502 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM3352：date 命令可以#39；t 在 SDK8.2中设置2039年。

admin
Guru**** 2549230 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1106780/am3352-date-command-can-t-set-the-year-2039-in-sdk8-2

器件型号：AM3352

在父线程中、有人提到"SDK 8.2使用 Linux 内核5.10。 因此、我希望 Y2038问题得到解决。"

我构建了 SDK8.2并将其引导。 然后我键入了日期命令、但 日期命令无法设置2039年、如下面所示。 

root@mmc-rmu:~# date -s 203801010000
Fri Jan  1 00:00:00 UTC 2038
root@mmc-rmu:~# date -s 203901010000
date: invalid date '203901010000'

尽管我检查了总线框的配置文件、但已定义"CONFIG_LINUX64=y"。 

uegaki@admine330-Precision-3520:~/ex1/rmu/tisdk8/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neon-linux-gnueabi/busybox/1.31.1-r0.arago21.tisdk0/busybox-1.31.1$ grep CONFIG_LINUX .config
CONFIG_LINUXRC=y
CONFIG_LINUX32=y
CONFIG_LINUX64=y

为什么指定2039时 date 命令失败？
您能告诉我如何解决此问题吗？

  • 0
    TI__Guru**** 2549230 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好 Naoto、

    我们下周再见。

    感谢您的耐心等待。

    此致、

    ＿＿＿＿＿＿＿＿＿

  • 0
    TI__Guru**** 2549230 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好 Naoto、

    有趣。 我的印象是、这应该开箱即用、但我看到的行为与您相同： 

    root@am335x-evm:~# uname -a
Linux am335x-evm 5.10.100-g7a7a3af903 #1 PREEMPT Sat May 14 22:36:58 UTC 2022 armv7l armv7l armv7l GNU/Linux
root@am335x-evm:~# date --date="01/01/2039"
date: invalid date '01/01/2039'
root@am335x-evm:~#
date --date="01/01/2038"
Fri Jan  1 00:00:00 UTC 2038

    让我做一些背景研究、然后返回给您。 如果我在下周初没有回复、请 Ping 该主题。

    此致、

    Nick

  • 0
    TI__Guru**** 2549230 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好 Naoto、

    我 正在与开发人员进行一些讨论、但我还没有任何重大更新。 如果我在一周结束前没有回复、请 Ping 该主题。

    此致、

    Nick

  • 0
    TI__Guru**** 2549230 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    感谢你的答复。

    顺便说一下、我认为这个问题的原因是 time_t 编译为32位、因为这是 glibc 的默认设置。 解决这个问题似乎有两种方法。 一种方法是为 glibc 使用"-D_TIME_bits=64 -D_file_offset_bits=64"选项将 TIME_t 编译为64位。 这需要 gcc-arm-11.2 (不能使用 gcc-arm-9.2)。 另一种方法是使用 musl 而不是 glibc、因为 musl 默认将 time_t 编译为64位。

    所以、我尝试使用 MUSL。 虽然我在 local.conf 中添加了 TCLIBC ="musl"、但 bitbake Building 却失败了。
    现在、我尝试使用 gcc-arm-11.2和"-D_TIME_bits=64 -D_file_offset_bits=64"。 但我遇到了一些错误、所以我正在调查。 如果我有一些更新、我将通知您。

  • 0
    TI__Guru**** 2549230 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好 Naoto、

    这方面没有重大更新。 对于未来的读者来说、这个堆栈溢出答案很有帮助： https://stackoverflow.com/a/60709400/4623956

    我对 https://lkml.org/lkml/2020/1/29/355?anz=web 和 https://lwn.net/Articles/776435/的理解 是 Linux 内核5.10本身应该是 y2038安全的。 但是、在 Linux 内核基础上构建的应用程序可能仍使用32位计时器、因此客户需要注意 y2038。 我将与开发人员一起仔细检查这一点。

    您的观察结果看起来是正确的。 glibc 在默认情况下不符合 y2038 (即、默认值仍然是32位时间、因此您需要专门告知它将 time_t 编译为64位)这一事实非常重要。

    在哪里可以找到有关使用或不使用 y2038修复程序的 gcc-arm 版本的信息？

    此致、

    Nick

  • 0
    TI__Guru**** 2549230 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    > 在哪里可以找到有关 gcc-arm 版本可以使用或不能使用 y2038修复程序的信息？
    因为"_time_bits "字符串可以在 gcc-arm-11.2中找到、而在 gcc-arm-10.3中找不到、如下面所示。 

    uegaki@sdk1:~/ex1/rmu$ grep -r -e "\b_TIME_BITS\b" gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:#if defined _TIME_BITS
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:# if _TIME_BITS == 64
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:#   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:# elif _TIME_BITS == 32
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:#   error "_TIME_BITS=32 is not compatible with __TIMESIZE > 32"
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:#  error Invalid _TIME_BITS value (can only be 32 or 64-bit)
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1: -- Macro: _TIME_BITS
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1:       1. If ‘_TIME_BITS’ is undefined, the bit size of ‘time_t’ is
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1:       2. If ‘_TIME_BITS’ is defined to be 64, ‘time_t’ is defined to be
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1:       3. If ‘_TIME_BITS’ is defined to be 32, ‘time_t’ is defined to be
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1:     ‘_TIME_BITS=64’ can be defined only when ‘_FILE_OFFSET_BITS=64’ is
バイナリファイル gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-17 に一致しました
uegaki@sdk1:~/ex1/rmu$ 
uegaki@sdk1:~/ex1/rmu$ grep -r -e "\b_TIME_BITS\b" gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf
uegaki@sdk1:~/ex1/rmu$