Re: glibc 2.27: 3 weeks till release

[Rafal Luzynski <digitalfreak at lingonborough dot com>]

18.01.2018 12:21 Florian Weimer <fweimer@redhat.com> wrote:
>
>
> On 01/17/2018 11:36 PM, Carlos O'Donell wrote:
> > [...]
> > Officially speaking, statically linked applications which are not
> > recompiled to the new runtime are unsupported, everything else is
> > just an extension of the inevitable day when your static binary
> > fails to work with the installed data. The key is to provide a
> > fallback, in this case your setlocale() call would fail and you'd
> > get only C/POSIX builtins.
>
> But this might have to change. Static linking (with PIE) appears to be
> one of the more attractive ways to reduce indirect branches.
>
> Is there an easy way to change the locale data encoding so that
> statically linked binaries will simply ignore the extra bits introduced
> by the ALTMON change?

My knowledge about static linking (with or without PIE) is kinda limited
but I think that in order to make the binary locale data backward and
forward compatible some sanity tests in locale/loadlocale.c would have to
be relaxed.  For example, LC_TIME should have 159 entries but 111 entries
should be also OK because ALTMON arrays are optional and we could copy the
missing entries from MON arrays.  At the moment my patches do this when
converting the locale data source code into the binary version but not
when loading the binary data.  Now the sanity tests check if the LC_TIME
size is exactly 159 (that's after my patches are applied, 111 in the
currently existing version) and reject the locale data if this is different.
Of course, this change is impossible for the statically linked binaries
which already exist so this is not helpful for you.

I think that if you need to run existing binaries statically linked
against glibc on the future new Linux systems with new locale data
and you want localization to work as previously then the easiest
solution is to deliver the old locale data in the binary version and
put them in a directory pointed to by LOCPATH environment variable.
For the same reasons the same was true whenever the locale data size
was changed in the past.  I have not tested this solution, though.

Regards,

Rafal