[Top][All Lists]

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

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

From: Greg Troxel
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Sun, 15 Jan 2023 09:42:06 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix)

"Gary E. Miller" <> writes:

>> >> What happens if a library defines D_TIME_BITS 64 and makes
>> >> syscalls, and a program which is unaware of this defines 32 and
>> >> also makes sycalls? Or is the syscall switch per .o because the
>> >> names are #defined?  
>> >
>> > That can never happen.  
>> I don't see how different .o files are prohibited from having
>> different _TIME_SIZE_BITS, unless it leads to a link failure.
> You can always build bad .o.  But good practice is to build all .o
> in a program or binary with the same setting.  Otherwise a huge number
> of ways to fail.  That is why all gpsd c files start with:
> #include "../include/gpsd_config.h"  // must be before all includes

I was asking about an installed library built one way, and a program
built another.  It seems like they will have DT_NEEDED on two different
libc versions, which will end up somewhere between erroring at start and

How are you going to manage building gpsd to match the time_t size
choice made in dbus and libusb?  How is anyone else going to manage this
in the world of individual compilation unit choice?  The only paths I can
see are

  a distribution choosing a setting for all programs

  setting up two hierarchies of lib/bin for building each way

reply via email to

[Prev in Thread] Current Thread [Next in Thread]