[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘64-bit time_t on glibc 2.34 and up
From: |
Miroslav Lichvar |
Subject: |
Re: ✘64-bit time_t on glibc 2.34 and up |
Date: |
Tue, 17 Jan 2023 12:46:10 +0100 |
On Mon, Jan 16, 2023 at 01:39:01PM -0800, Gary E. Miller wrote:
> As for gpsd and libusb.h. Gpsd uses none of the timeval calls that
> libusb offers. NTPsec does not use libusb at all.
Ok, maybe gpsd is not impacted by the libraries it is using, but it
seems libgps is using some time_t fields, so they would need to be
replaced by int64_t or something to avoid breaking libgps applications
that don't use the same time_t.
> > gpsd could make it easier
> > for users compiling it themselves and check some known locations of
> > these global flags.
>
> I know of none. If you do, please forward them to us.
I'm not aware of any glibc-based distributions that made the
switch yet. It seems Gentoo is considering few different options:
https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration
On rpm-based systems the flags might appear in output of "rpm -E
%{build_cflags}", but we won't know for sure until it happens.
--
Miroslav Lichvar
Re: ✘64-bit time_t on glibc 2.34 and up, Hal Murray, 2023/01/14
Re: ✘64-bit time_t on glibc 2.34 and up, Miroslav Lichvar, 2023/01/16