On Wed, Sep 5, 2018 at 3:35 AM Christoph Berg <myon@debian.org> wrote:
> Re: Thomas Munro 2018-09-04 <CAEepm=0uEQCpfq_+LYFBdArCe4Ot98t1aR4eYiYTe=yavQygiQ@mail.gmail.com>
> > I was reminded about that by recent news
> > about an upcoming glibc/CLDR resync that is likely to affect
> > PostgreSQL users (though, I guess, probably only when they do a major
> > OS upgrade).
>
> Or replicating/restoring a database to a newer host.
Yeah.
> > Does anyone know
> > of a way to extract a version string from glibc using existing
> > interfaces? I heard there was an undocumented way but I haven't been
> > able to find it -- probably because I was, erm, looking in the
> > documentation.
>
> That sounds more robust. Googling around:
>
> https://www.linuxquestions.org/questions/linux-software-2/how-to-check-glibc-version-263103/
>
> #include <stdio.h>
> #include <gnu/libc-version.h>
> int main (void) { puts (gnu_get_libc_version ()); return 0; }
>
> $ ./a.out
> 2.27
>
> Hopefully that version info is fine-grained enough.
Hmm. I was looking for locale data version, not libc.so itself. I
realise they come ultimately from the same source package, but are the
locale definitions and libc6 guaranteed to be updated at the same
time? I see that the locales package depends on libc-bin >> 2.27 (no
upper bound), which in turn depends on libc6 >> 2.27, << 2.28. So
perhaps you can have a system with locales 2.27 and libc6 2.28? I
also wonder if there are some configurations where they could get out
of sync because of manual use of locale-gen or something like that.
Clearly most systems would have them in sync through apt-get upgrade
though, so maybe gnu_get_libc_version() would work well in practice?
--
Thomas Munro
http://www.enterprisedb.com