[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Y2038] debian/armhf time64 build?

On Wed, Sep 28, 2022, at 9:07 AM, Dominique MARTINET wrote:
> Arnd Bergmann wrote on Wed, Sep 28, 2022 at 08:21:00AM +0200:
> Ugh, this is going to be a massive headache...
> Other distributions I've worked with (e.g. nixos) have a wrapper for gcc
> and clang that just enforce the flags they want the distro to be built
> with -- I don't think debian has anything like that, would that be
> easier to work with? My line of thinking is that there will only be a
> single place to fix instead of configure/cmake/meson and all hand-made
> build scripts that exist around here.

Passing the flags to the C compiler is not the issue here, this can
be done in the gcc and clang packages directly by defining the right
set of macros (with the minor annoyance that glibc itself expects to
be built without those flags, but that again can obviously be solved).

> Alternatively this would be delaying things even further to get a new
> glibc version, but have a glibc build option that just makes this the
> default and rebuild that debian repo with it?
> afaik that's what musl has done in commit 38143339646a ("switch all
> existing 32-bit archs to 64-bit time_t"):
> https://git.musl-libc.org/cgit/musl/commit/?id=38143339646a4ccce8afe298c34467767c899f51

That is what I had proposed years ago when the glibc developers
started their work, but this was rejected as they do not wan to
change the default behavior for a given architecture, or make
the ABI conditional based on a compile-time flag during
compilation of the libc.

Again, this is just an implementation detail for getting things
running, the hard question that I want to postpone is what to do
about having both types of armhf debian packages (time32 and
time64) coexist on a single file system and instead focus on
the actual bootstrapping to find all the packages that break
just because of the time_t change.


Reply to: