Re: Proposed CHOST change for the 64bit time_t transition

Todd Vierling <[email protected]> Thu, 5 Sep 2024 16:33:34 +0000
Newsgroups dev.linux.lists.distributions
Message-ID <CO1PR10MB467524D51DAB97012807DE11929D2@CO1PR10MB4675.namprd10.prod.outlook.com>
> One possible improvement would be to append "t32" if you want 32-bit=0A=
> time_t, instead of appending "t64" for 64-bit time_t.=0A=
=0A=
Versioned symbols in glibc should mean that old binaries will still run (ev=
en if they misbehave when they look at the system time), just like with mos=
t previous ABI changes to libc over the years. Generally the triplet has ne=
ver changed except to flag that something is being intentionally built for =
an *older* API/ABI. For instance, autoconf had for some time a separate tri=
plet to identify a.out/libc5/glibc1 when ELF/libc6/glibc2 had become the ne=
w standard, flagging the deprecated rather than current revision.=0A=
=0A=
Like previous base libc ABI changes, yes, it means rebuilding all downstrea=
m libraries and applications to make use of the new API/ABI. What matters i=
s whether it's "easy" to pick up a mix of shared objects built for differen=
t ABIs which are representing a data type differently. The thing being aske=
d here is fundamentally a search for a technical solution to this risk, but=
 changing a triplet alone doesn't address that risk at all.=0A=
=0A=
Some technical options to address the actual question include:=0A=
=0A=
1. Total flag day. No versioned symbols, no compatibility.=0A=
=0A=
2. Partial flag day. Provide only the bare minimum of compatibility librari=
es, and intentionally change the versions (sonames) of libc-downstream libr=
aries so that new binaries won't pick the old libraries. Applications that =
dlopen("libfoo.so") will break, but... please don't dlopen() an unversioned=
 .so filename kthx because that already risks ABI breakage.=0A=
=0A=
3. Keep new libraries partitioned; no more installing directly into /usr/li=
b{,64} depending on your distro, rather everything must now go in a new pla=
ce, and the dynamic linker needs to know which paths to use and which to ig=
nore. This would require new executables being tagged in some form at link =
time.=0A=
=0A=
4. Same as (3), but the dynamic linker needs to know where *compatibility* =
libraries are installed for older binaries, and choose that path in prefere=
nce instead of the standard one. Still requires new executables being tagge=
d to tell the difference.=0A=
=0A=
-- =0A=
-- Todd Vierling, Oracle Linux Sustaining and Security <todd.vierling@oracl=
e.com>=0A=