Re: --disable-versioning and --enable-oldest-abi

[Roland McGrath <roland at hack dot frob dot com>]

I concur on both counts.

I can see potential reasons for using both options if they worked.
But since they don't work and nobody wants to use them enough to try
to fix them, we're better off not having them.

Fixing --enable-oldest-abi is probably not very hard.  I think a
working implementation would have the exact same effect as replacing
the third column in all matching lines of shlib-versions, which should
not be hard to simulate.  But we should not speculatively attempt to
fix it.  We should take it out since it's broken, and put it back only
when someone makes it work, verifies it works, documents it clearly,
will actually use it for builds they test thoroughly, and commits to
keeping it working.

The use case for --enable-oldest-abi is someone building a new variant
system that has no interest in ABI compatibility with any pre-existing
binaries but is concerned about minimizing bloat and dead code in the
build.  The use case for --disable-versioning is similar, but for a
case where not only does one not care to support binaries that existed
before the creation of the variant system, but will absolutely never
update libc without rebuilding every application in the system--and is
especially concerned about code size and efficiency, so the extra text
sections and extra dynamic linker work for version set handling is
really worth avoiding.  (For example, an "embedded GNU/Linux" system
on a sealed device that cannot accept new applications or DSOs without
a complete replacement of the whole system image.)

In practice people with those sorts of use cases generally use
different libc implementations that are much smaller and less
featureful in more substantial ways than these.

In theory ChromeOS seems like a use case of this sort where they do
actually want a mostly full-featured libc.  But in practice, even
though it does qualify as a "sealed device" case as described above,
it does include some binaries from other places that cannot easily be
rebuilt with a new ABI whenever libc and most of the system gets
rebuilt.

So I don't foresee anybody actually wanting to use these options for
at least a few years to come.  That's more than long enough that we're
better off reducing the complexity of the codebase now and revisiting
how to implement things like this only when we have users articulating
concrete use cases.


Thanks,
Roland