> One possible improvement would be to append "t32" if you want 32-bit
> time_t, instead of appending "t64" for 64-bit time_t.
Versioned symbols in glibc should mean that old binaries will still run (even
if they misbehave when they look at the system time), just like with most
previous ABI changes to libc over the years. Generally the triplet has never
changed except to flag that something is being intentionally built for an
*older* API/ABI. For instance, autoconf had for some time a separate triplet to
identify a.out/libc5/glibc1 when ELF/libc6/glibc2 had become the new standard,
flagging the deprecated rather than current revision.
Like previous base libc ABI changes, yes, it means rebuilding all downstream
libraries and applications to make use of the new API/ABI. What matters is
whether it's "easy" to pick up a mix of shared objects built for different ABIs
which are representing a data type differently. The thing being asked here is
fundamentally a search for a technical solution to this risk, but changing a
triplet alone doesn't address that risk at all.
Some technical options to address the actual question include:
1. Total flag day. No versioned symbols, no compatibility.
2. Partial flag day. Provide only the bare minimum of compatibility libraries,
and intentionally change the versions (sonames) of libc-downstream libraries 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.
3. Keep new libraries partitioned; no more installing directly into
/usr/lib{,64} depending on your distro, rather everything must now go in a new
place, and the dynamic linker needs to know which paths to use and which to
ignore. This would require new executables being tagged in some form at link
time.
4. Same as (3), but the dynamic linker needs to know where *compatibility*
libraries are installed for older binaries, and choose that path in preference
instead of the standard one. Still requires new executables being tagged to
tell the difference.
--
-- Todd Vierling, Oracle Linux Sustaining and Security
<todd.vierl...@oracle.com>
