Hi Todd, > 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.
That is irrelevant here. glibc takes care of its own interface and is not a
problem.
The types exported by glibc, as used in *other* libraries' interfaces, are the
problem.
> 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.
That's incorrect, else we wouldn't have -gnueabi (on arm) or -gnuabin32 (on
mips).
> 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.
Maybe not alone, but it minimizes the risk of accidental confusion, and makes
100%
clear which ABI is present.
>
> Some technical options to address the actual question include:
>
Most of this is actually irrelevant to the specific question I'm asking,
because...
> 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.
... how this is done exactly during the transition is something each
distribution can
easily organize on their own. Doesn't mean we can't talk about it, but it's
right now and
in this context not important.
> 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 e
> xecutables being tagged in some form at link time.
Yes. I was already joking about 'libt64'. (That was a JOKE, please please
please dont
take it serious.)
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
signature.asc
Description: This is a digitally signed message part.
