Re: features-time64.h on non-linux 32b platforms
Samuel Thibault <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha |
|---|---|
| Organization | I am not organized |
| Message-ID | <ao1UkDtBbzVr-g9X@end> |
Hello, Paul Eggert, le mar. 25 août 2026 00:39:03 -0700, a ecrit: > On 2026-08-25 00:01, Samuel Thibault wrote: > > Paul Eggert, le lun. 24 août 2026 23:56:14 -0700, a ecrit: > > > Which app defines _TIME_BITS=64 and blindly expects that to work on hurd-i386? > > > > gcli does. > > I don't see _TIME_BITS mentioned in the gcli source code that I got from <https://gitlab.com/herrhotzenplotz/gcli.git>. Are we talking about the same gcli? > > Did someone attempt to configure that gcli with './configure CFLAGS=-D_TIME_BITS=64' and complain that the build silently ignored _TIME_BITS? Yes, it's in the debian packaging, to fix its testsuite on i386 which will not migrate to _TIME_BITS set to 64 by default: https://sources.debian.org/src/gcli/2.13.0-2/debian/rules > If it would be useful for builds like that to fail, perhaps you could add an #error check to glibc's sysdeps/mach/hurd/bits/timesize.h. That would be less intrusive than messing with sysdeps/generic etc. Yes, in theory one should make such a change generic to all 32-bit-only time_t platforms, but when there is only one such platform.... Ok. Samuel