From: "Arnaud Panaïotis" <arnaud.panaiotis@gmx.fr>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Arnd Bergmann <arnd@kernel.org>,
y2038@lists.linaro.org, libc-alpha@sourceware.org,
linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel
Date: Tue, 31 May 2022 15:24:35 +0200 [thread overview]
Message-ID: <ba006409-2054-fe83-2b62-996d89f527f9@gmx.fr> (raw)
In-Reply-To: <YpYR6E9MWJObVtN6@arm.com>
On 31/05/2022 15:02, Szabolcs Nagy wrote:
> The 05/31/2022 14:16, Arnaud Panaïotis via Libc-alpha wrote:
>>>>> If I'm reading this correctly, daemon() internally uses the time32
>>>>> version of 'stat', which fails for files with out-of-range timestamps.
>>>>> Are you able to rebuild the ssh binary (or your entire distro, if that's
>>>>> easier) against musl-1.2.x instead of glibc to see if the same thing
>>>>> happens there?
>> Musl did not worked previously for me, not sure for openssh only within
>> Buildroot.
> did you have a specific issue with musl?
>
> it is supposed to work with buildroot and
> has 64bit time_t support out of the box.
Not really, I'm working on an existing project that was developed before
with Glibc. If I remember correctly some packages used by the project
did not build with musl (even with the previous version of Kernel).
The purpose of my mission was to analyze how to pass y2038 on embedded
devices (2 Linux and 1 Windows), now is to build the solution.
Upgrading Glibc and Buildroot were easier than switching to musl due
what was done before. I probably would have to change many elements
(packages, init scripts...) if I'd switched to musl.
Now both y2038 Linux works with glibc, this subject is the third I
raised (mysqld solved by a patch I made, cp binutils with issue from
fchmodat (bug 29097)).
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
prev parent reply other threads:[~2022-05-31 13:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAK8P3a0bmE03wJ_iELrAMyFvamwd_r5aLsFBH=6=5YaueO=-kg@mail.gmail.com>
2022-05-31 8:33 ` Arnd Bergmann
2022-05-31 9:02 ` Arnaud Panaïotis
2022-05-31 10:54 ` Adhemerval Zanella
2022-05-31 12:16 ` Arnaud Panaïotis
2022-05-31 13:02 ` Szabolcs Nagy
2022-05-31 13:24 ` Arnaud Panaïotis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba006409-2054-fe83-2b62-996d89f527f9@gmx.fr \
--to=arnaud.panaiotis@gmx.fr \
--cc=adhemerval.zanella@linaro.org \
--cc=arnd@kernel.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=szabolcs.nagy@arm.com \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).