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

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> 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
UB.

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