On Wed, Sep 5, 2018 at 3:35 AM Christoph Berg <m...@debian.org> wrote: > Re: Thomas Munro 2018-09-04 > <CAEepm=0uEQCpfq_+LYFBdArCe4Ot98t1aR4eYiYTe=yavqy...@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
