lib/libc/Versions.def: new symbol version for 12.x

[Ed Schouten]

Hi there,

In a couple of weeks from now I'm going to add new versions of
basename() and dirname() to libc that are thread-safe. These should
now use symbol version "FBSD_1.5", but a question that emaste@ and I
have is: why don't these symbol version names follow the major
versions of FreeBSD? As in, why not call this "FBSD_12.0" instead?

Thoughts?

[Daniel Eischen]

Post by Ed Schouten
Hi there,
In a couple of weeks from now I'm going to add new versions of
basename() and dirname() to libc that are thread-safe. These should
have is: why don't these symbol version names follow the major
versions of FreeBSD? As in, why not call this "FBSD_12.0" instead?

New symbol versions can be rolled back to -stable or other prior
baselines. Also, if there are no changes in a major release branch,
there's no need to bump the symbol version. It's just an arbitrary
number somewhat tied to major release versions by convention. I
started it at 1.0 when I first added symbol versioning, so you can
probably blame me ;-)

[Ed Maste]

Post by Daniel Eischen
New symbol versions can be rolled back to -stable or other prior
baselines.

If that happens I think having an FBSD_12.0 symbol in stable/11
actually makes it more clear what's happening, than if a FBSD_1.5
symbol appears in stable/11.

Post by Daniel Eischen
Also, if there are no changes in a major release branch,
there's no need to bump the symbol version.

That's fine too, the version would just jump from FBSD_10.0 to
FBSD_12.0 for example.

[Ed Schouten]

Post by Ed Maste

Post by Daniel Eischen
New symbol versions can be rolled back to -stable or other prior
baselines.

If that happens I think having an FBSD_12.0 symbol in stable/11
actually makes it more clear what's happening, than if a FBSD_1.5
symbol appears in stable/11.

Yes, exactly. The version number would just indicate the version of
-CURRENT that was used to introduce the symbol. If we would be going
down this road, then I have to further questions:

- Should we drop the .0 suffix then?
- Would it make sense to also name it to 'FreeBSD' instead of 'fBSD'?

That is, using 'FreeBSD_12' as the next symbol version.

[Daniel Eischen]

Sent from my iPhone

Post by Ed Schouten

Post by Ed Maste

Post by Daniel Eischen
New symbol versions can be rolled back to -stable or other prior
baselines.

If that happens I think having an FBSD_12.0 symbol in stable/11
actually makes it more clear what's happening, than if a FBSD_1.5
symbol appears in stable/11.

Yes, exactly. The version number would just indicate the version of
-CURRENT that was used to introduce the symbol. If we would be going
- Should we drop the .0 suffix then?
- Would it make sense to also name it to 'FreeBSD' instead of 'fBSD'?
That is, using 'FreeBSD_12' as the next symbol version.

They were originally modeled similar to Solaris (and Linux to some extent, IIRC):

https://docs.oracle.com/cd/E19683-01/806-4125/solarisabi-8/index.html

I think there's not much point of changing the naming scheme now, it's not like it's visible to the typical user. The comment in the Version.defs file pretty much explains everything.

[Konstantin Belousov]

Post by Daniel Eischen
https://docs.oracle.com/cd/E19683-01/806-4125/solarisabi-8/index.html
I think there's not much point of changing the naming scheme now, it's not like it's visible to the typical user. The comment in the Version.defs file pretty much explains everything.

What we have currently in the symbol versioning scheme definitely has
nothing common with Solaris, and has only slight resemblance to the
glibc variant. Our rtld implements the GNU extention of the original
Solaris versioning, but the way we provide actual versioning in shipped
libraries defeats some useful parts of the functionality.

The original Solaris scheme, AFAIR, has the goal of preventing binary
linked to a newer library, even to try to start with the older version of
the library. Solaris libc, when introducing a new symbol, also added a new
version to the list of versions implemented by the library. On startup,
dynamic linker verifies that all referenced versions are present in the
library.

This is needed since default binding resolution is lazy, and missed
symbol goes undetected until called. As result, applications fail hard
somewhere at runtime, surprising users and corrupting data, unless
checked.

We do exactly opposite, all symbols added during the CURRENT-X
development cycle, are added into single namespace. This would be not
too bad, we do not care much about CURRENT ABI until it is backward
compatible, but we also merge symbols to stable branches under same
namespace. The result is that you cannot distinguish older and newer
libraries from the same stable branch at the startup linking.

From what I remember, both Solaris and glibc create new namespace for
each symbols addition. GNU scheme has more flexibility by allowing to
change ABI of symbols, and this is the only feature we use in limited
form (we cannot provide ABI compat shims for symbols which change more
than once during one CURRENT cycle).

IMO it does not make sense to change current scheme without fixing the
bug I described above. Any change in naming makes the things even more
confusing, and imposing the pain only for somebody aestetic feel does
not look right.