Re: ✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Miroslav!

On Tue, 17 Jan 2023 12:46:10 +0100
Miroslav Lichvar <mlichvar@redhat.com> wrote:

> 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.

I'll look at that.  Anything in particular?

> > > 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

Oh my, I see they got some facts wrong on that page.  I'll comment to
the Gentoo folks on Wednesday.

Gentoo sorta waits until there are package conflicts, then works to
sort things out.  gpsd will now do its best to add to those
conflicts.  :-)

> 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.

Yup,  all guesswork, until someone breaks something.

Are you going to patch chronyd with your variable length sock idea?
Current gpsd git head is a good test case for that.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpHqbvZxiQFj.pgp
Description: OpenPGP digital signature