Deal with changing sonames and removed symbols

[alexrp]

NetBSD is unusual compared to glibc and FreeBSD libc in that they've been signaling for years that they would like to bump the major version in the sonames of some core libraries:

• https://github.com/NetBSD/src/blob/trunk/lib/libc/shlib_version
• https://github.com/NetBSD/src/blob/trunk/lib/libm/shlib_version
• https://github.com/NetBSD/src/blob/trunk/lib/libpthread/shlib_version

Now, of the libraries we care about, the most recent bumps were on:

• libc: Oct 20, 1997
• libexecinfo: May 26, 2012 (when the library was introduced)
• libm: Feb 15, 1994
• libpthread: Jan 11, 2009 (64-bit time_t transition)
• librt: Jan 11, 2009 (64-bit time_t transition)
• libutil: Nov 30, 2002

So clearly this isn't an imminent concern. But there's precedent, and it could very well happen again, so we should figure out a way of dealing with it.

Related reading:

• https://www.netbsd.org/docs/elf.html
• https://wiki.netbsd.org/symbol_versions

[alexrp]

One option here is to just not care, i.e. we'd keep providing symbols that have been removed, even when targeting newer major versions. I don't think this would be hugely problematic unless there's code explicitly referencing those symbols, but then that code would be broken anyway when targeting a newer major version. The obvious downside is that what would have been a link failure becomes a run-time error.

[alexrp]

One option here is to just not care, i.e. we'd keep providing symbols that have been removed, even when targeting newer major versions. I don't think this would be hugely problematic unless there's code explicitly referencing those symbols, but then that code would be broken anyway when targeting a newer major version. The obvious downside is that what would have been a link failure becomes a run-time error.

This can be particularly problematic for build-time feature tests, as seen in ziglang/zig#24241.