speller
speller

Reputation: 1741

Why does glibc have 2 versions of the same functions?

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 "backward compatible" in glibc and a new GLIBC_2.X version needs to be introduce?

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 do fnmatch even has 2 versions? What other causes are there for the developers to start a "new version" of a function?

Upvotes: 2

Views: 763

Answers (1)

vinc17
vinc17

Reputation: 3466

The interface also changes in case of ABI change, e.g. some change in an internal structure that could be visible by code compiled against an old version of the library. This needs new versioned symbols.

By default, when compiling code, the current version is chosen. Old versions are also provided by the glibc to allow one to get binaries (provided by the vendor) compiled with old glibc versions and run them on one's machine (which has a newer glibc version).

Upvotes: 2

Related Questions