illumos gate

Webrev: http://cr.illumos.org/~webrev/andy_js/5709/

If you do this, it's important that the version have exactly the same symbols in it.

If that's the case here, it's a fine thing to do.

That is the case. The new version only includes 4 symbols.

Updated webrev: http://cr.illumos.org/~webrev/andy_js/5709-1

In the end, we're electing to introduce a dummy symbol into an otherwise empty version.

As per analysis from Andy Fiddaman:

Options:

• Option 1: move symbols to new SUNW_1.22.7 version
  • Any old binaries that use the symbols work fine everywhere - they don't even have a dependency on version 1.22.7.
  • Any binaries compiled with the new C library have a dependency on the 1.22.7 version so will not run on an older illumos system which does not have it.
  • binaries from Solaris 10u10 with a dependency on version 1.22.7 work.

• Option 2: add empty SUNW_1.22.7 version
  • new binaries do not use the dummy symbol so will not end up with a dependency on the new version
  • new and old binaries run on any illumos system.
  • binaries from Solaris 10u10 with a dependency on version 1.22.7 work.

While our release model does allow us to introduce this is as an ABI break from r151026 onwards, option 2 avoids this and also preserves interoperability with other illumos releases regardless of whether they have added this version to their libc.

Note that the dummy symbol in the version we're introducing is necessary to avoid the linker creating a weak version, which behaves differently to the version in the analogous Solaris 10 libc that we are trying to emulate.

The Linkers and Libraries Guide suggests that a weak version definition is to signal "changes to an object that do not require the introduction of a new interface definition"; e.g., bug fixes or performance improvements. It says that weak versions are created by specifying a version that contains no additional symbols, basically.

In addition, it mentions that "[a version's] weak nature precludes its normalisation with [other symbol versions], and results in a separate dependency recording".