I don't fully understand the versioning mechanism of glibc.

In what cases do the developers decide a function needs a new version, and that function is no longer "backwards compatible" in glibc and a new GLIBC_2.X version needs to be introduced?

In the case of a function's prototype change, or an API change, I understand, but what more causes are there?

i.e. fnmatch:

I'm looking at a readelf output on my glibc 2.19 and I see 2 versions of fnmatch:

151: 000bff40   892 FUNC    GLOBAL DEFAULT   12 fnmatch@GLIBC_2.0
152: 000bff40   892 FUNC    GLOBAL DEFAULT   12 fnmatch@@GLIBC_2.2.3

But when I look at glibc's code, I see they are exactly the same function:

versioned_symbol (libc, __fnmatch, fnmatch, GLIBC_2_2_3);
#  if SHLIB_COMPAT(libc, GLIBC_2_0, GLIBC_2_2_3)
strong_alias (__fnmatch, __fnmatch_old)
compat_symbol (libc, __fnmatch_old, fnmatch, GLIBC_2_0);
#  endif

So why does fnmatch even have 2 versions? What other causes are there for the developers to start a "new version" of a function?

closed as off-topic by Gilles, Michael Homer, Anthon, jasonwryan, jimmij Feb 22 '15 at 22:56

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question has been posted on multiple sites. Cross-posting is strongly discouraged; see the help center and community FAQ for more information." – Gilles, Michael Homer, Anthon, jasonwryan, jimmij

Browse other questions tagged or ask your own question.