locale: Make the file name of the locale archive configurable
Commit Message
This improves support for parallel installation and upgrade scenarios
involving changes to the locale archive format or the data stored in
it.
2019-06-04 Florian Weimer <fweimer@redhat.com>
* configure.ac: Handle --locale-archive-name.
(LOCALE_ARCHIVE_NAME): Define.
(locale_archive_name): Substitute.
* config.h.in (LOCALE_ARCHIVE_NAME): Undefine.
* config.make.in (locale-archive-name): Define.
* locale/loadarchive.c (archfname): Use LOCALE_ARCHIVE_NAME.
* locale/programs/locale.c (ARCHIVE_NAME): Likewise.
* locale/programs/locarchive.c (ARCHIVE_NAME): Likewise.
* manual/install.texi (Configuring and compiling): Document
--with-locale-archive-name.
* configure, INSTALL: Regenerate.
Comments
Hi,
Le mardi 04 juin 2019 à 15:40 +0200, Florian Weimer a écrit :
> This improves support for parallel installation and upgrade scenarios
> involving changes to the locale archive format or the data stored in
> it.
>
This could hurt exchanging statically linked programs between Linux
distributions: I think of this scenario where one program is built on
Debian and it won't be able to find the locale archive on Fedora.
I'm not afraid of this kind of breakage when it comes to statically
linked program (because of gconv, nss, and such), but it would require
some warning in the documentation.
Perhaps a fallback to the current default path could be implemented
along this change ?
Regards.
On 6/4/19 1:35 PM, Yann Droneaud wrote:
> Hi,
>
> Le mardi 04 juin 2019 à 15:40 +0200, Florian Weimer a écrit :
>> This improves support for parallel installation and upgrade scenarios
>> involving changes to the locale archive format or the data stored in
>> it.
>>
>
> This could hurt exchanging statically linked programs between Linux
> distributions: I think of this scenario where one program is built on
> Debian and it won't be able to find the locale archive on Fedora.
This is a completely unsupported scenario.
It broke recently when we added %OB/%Ob support.
This has never been supported and is actively discouraged.
The static binary must have exactly the same runtime as it was compiled
with for the execution of all APIs to work correctly.
You cannot use static linkage as a method for creating portable binaries
because it is not that.
> I'm not afraid of this kind of breakage when it comes to statically
> linked program (because of gconv, nss, and such), but it would require
> some warning in the documentation.
We can certainly add more warnings.
> Perhaps a fallback to the current default path could be implemented
> along this change ?
I don't want to see a fallback, it sends the wrong message.
If we want someone can work on an ABI or "version" markup which might
allow a static binary to know if the binary data on disk is in a
format that it might be able to load. That might be useful.
* Yann Droneaud:
> Le mardi 04 juin 2019 à 15:40 +0200, Florian Weimer a écrit :
>> This improves support for parallel installation and upgrade scenarios
>> involving changes to the locale archive format or the data stored in
>> it.
>>
>
> This could hurt exchanging statically linked programs between Linux
> distributions: I think of this scenario where one program is built on
> Debian and it won't be able to find the locale archive on Fedora.
>
> I'm not afraid of this kind of breakage when it comes to statically
> linked program (because of gconv, nss, and such), but it would require
> some warning in the documentation.
Hmm. That's right. I think we need to solve our little problem in
another way.
Technically, statically linked binaries are not portable today, but we
should move in the other direction, not towards more incompatibilities.
Thanks,
Florian
4.06.2019 20:05 Carlos O'Donell <carlos@redhat.com> wrote:
> [...]
> If we want someone can work on an ABI or "version" markup which might
> allow a static binary to know if the binary data on disk is in a
> format that it might be able to load. That might be useful.
What about a forward/backward compatible binary format of the locale
archive? The format should describe what data it provides, what are
the offsets and sizes of the records etc. so an executable would be
even able to support the future archive formats or at least would be
able to tell that it cannot support the format for good reasons.
I think that if a locale archive file is opened by mmap then supporting
architectures with different endiannesses would be the biggest difficulty
(so a package with all locales couldn't be noarch) but if you think
about the parallel installation of e.g., i686 and x86_64 packages then
in these pairs they could co-exist.
Regards,
Rafal
On 6/6/19 6:12 PM, Rafal Luzynski wrote:
> 4.06.2019 20:05 Carlos O'Donell <carlos@redhat.com> wrote:
>> [...]
>> If we want someone can work on an ABI or "version" markup which might
>> allow a static binary to know if the binary data on disk is in a
>> format that it might be able to load. That might be useful.
>
> What about a forward/backward compatible binary format of the locale
> archive? The format should describe what data it provides, what are
> the offsets and sizes of the records etc. so an executable would be
> even able to support the future archive formats or at least would be
> able to tell that it cannot support the format for good reasons.
We could do this quite easily.
We just need a header and an ABI version field.
And we need to have the discipline to alter the version field when we
adde new data like %OB/%Ob.
> I think that if a locale archive file is opened by mmap then supporting
> architectures with different endiannesses would be the biggest difficulty
> (so a package with all locales couldn't be noarch) but if you think
> about the parallel installation of e.g., i686 and x86_64 packages then
> in these pairs they could co-exist.
I think that supporting multiple different architectures from the same
data set is a non-goal, with the exception of multilib arches on the same
machine like i686 and x86_64 (same endianness and very similar features).
7.06.2019 02:22 Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 6/6/19 6:12 PM, Rafal Luzynski wrote:
> > [...]
> > What about a forward/backward compatible binary format of the locale
> > archive? The format should describe what data it provides, what are
> > the offsets and sizes of the records etc. so an executable would be
> > even able to support the future archive formats or at least would be
> > able to tell that it cannot support the format for good reasons.
>
> We could do this quite easily.
>
> We just need a header and an ABI version field.
This will just prevent the executables from using an incompatible locale
archive rather than enable them to use any format. Which is of course
still better than allowing any executable to use any locale archive
and let it fail silently (or work correctly if we are lucky). It is
OK if you think this is sufficient.
Regards,
Rafal
On 6/7/19 6:42 AM, Rafal Luzynski wrote:
> 7.06.2019 02:22 Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> On 6/6/19 6:12 PM, Rafal Luzynski wrote:
>>> [...]
>>> What about a forward/backward compatible binary format of the locale
>>> archive? The format should describe what data it provides, what are
>>> the offsets and sizes of the records etc. so an executable would be
>>> even able to support the future archive formats or at least would be
>>> able to tell that it cannot support the format for good reasons.
>>
>> We could do this quite easily.
>>
>> We just need a header and an ABI version field.
>
> This will just prevent the executables from using an incompatible locale
> archive rather than enable them to use any format. Which is of course
> still better than allowing any executable to use any locale archive
> and let it fail silently (or work correctly if we are lucky). It is
> OK if you think this is sufficient.
I think this is sufficient first step.
A subsequent step is obviously to make an extensible binary format, but
that is another and orthogonal problem.
On Thu, 6 Jun 2019, Carlos O'Donell wrote:
> > I think that if a locale archive file is opened by mmap then supporting
> > architectures with different endiannesses would be the biggest difficulty
> > (so a package with all locales couldn't be noarch) but if you think
> > about the parallel installation of e.g., i686 and x86_64 packages then
> > in these pairs they could co-exist.
>
> I think that supporting multiple different architectures from the same
> data set is a non-goal, with the exception of multilib arches on the same
> machine like i686 and x86_64 (same endianness and very similar features).
Endianness should be the only incompatibility between locale files for
different systems with the same glibc version (see the NEWS entries for
2.19 for previous incompatibilities that were eliminated as part of
enabling localedef to be used with --big-endian or --little-endian to
generate locales for a different system).
Although some architectures do support changing endianness at runtime, the
Linux kernel has never supported running other-endian processes like that
(and so none of the multilib directory arrangements used by glibc support
different directories for different endianness, although Debian multiarch
tuples do).
@@ -106,6 +106,14 @@ if 'CFLAGS' is specified it must enable optimization. For example:
particular case and potentially change debugging information and
metadata only).
+'--with-locale-archive-name=NAME'
+ Use NAME as the file name of the locale archive, and not the
+ default 'locale-archive'. Usually, the locale archive is stored in
+ the directory '/usr/lib/locale' (for both 32-bit and 64-bit
+ targets). For parallel installation of partially compatible
+ versions of the GNU C Library, this option can be used to alter the
+ name of the file used by glibc and by the 'localedef' tool.
+
'--disable-shared'
Don't build shared libraries even if it is possible. Not all
systems support shared libraries; you need ELF support and
@@ -189,6 +189,9 @@
/* Define if the linker defines __ehdr_start. */
#undef HAVE_EHDR_START
+/* The file name of the locale archive (without the directory). */
+#undef LOCALE_ARCHIVE_NAME
+
/*
*/
@@ -23,6 +23,7 @@ datarootdir = @datarootdir@
localstatedir = @libc_cv_localstatedir@
localedir = @localedir@
multidir= @libc_cv_multidir@
+locale-archive-name = @locale_archive_name@
# Should we use and build ldconfig?
use-ldconfig = @use_ldconfig@
@@ -687,6 +687,7 @@ hardcoded_path_in_tests
enable_timezone_tools
extra_nonshared_cflags
use_default_link
+locale_archive_name
sysheaders
ac_ct_CXX
CXXFLAGS
@@ -763,6 +764,7 @@ with_gd_lib
with_binutils
with_selinux
with_headers
+with_locale_archive_name
with_default_link
with_nonshared_cflags
enable_sanity_checks
@@ -1484,6 +1486,9 @@ Optional Packages:
--with-selinux if building with SELinux support
--with-headers=PATH location of system headers to use (for example
/usr/src/linux/include) [default=compiler default]
+ --with-locale-archive-name=NAME
+ file name of the locale archive
+ [default=locale-archive]
--with-default-link do not use explicit linker scripts
--with-nonshared-cflags=CFLAGS
build nonshared libraries with additional CFLAGS
@@ -3335,6 +3340,20 @@ fi
+# Check whether --with-locale-archive-name was given.
+if test "${with_locale_archive_name+set}" = set; then :
+ withval=$with_locale_archive_name; locale_archive_name=$withval
+else
+ locale_archive_name=locale-archive
+fi
+
+cat >>confdefs.h <<_ACEOF
+#define LOCALE_ARCHIVE_NAME "$locale_archive_name"
+_ACEOF
+
+
+
+
# Check whether --with-default-link was given.
if test "${with_default_link+set}" = set; then :
@@ -147,6 +147,15 @@ AC_ARG_WITH([headers],
[sysheaders=''])
AC_SUBST(sysheaders)
+AC_ARG_WITH([locale-archive-name],
+ AC_HELP_STRING([--with-locale-archive-name=NAME],
+ [file name of the locale archive
+ @<:@default=locale-archive@:>@]),
+ [locale_archive_name=$withval],
+ [locale_archive_name=locale-archive])
+AC_DEFINE_UNQUOTED(LOCALE_ARCHIVE_NAME, "$locale_archive_name")
+AC_SUBST(locale_archive_name)
+
AC_SUBST(use_default_link)
AC_ARG_WITH([default-link],
AC_HELP_STRING([--with-default-link],
@@ -42,7 +42,7 @@
/* Name of the locale archive file. */
-static const char archfname[] = COMPLOCALEDIR "/locale-archive";
+static const char archfname[] = COMPLOCALEDIR "/" LOCALE_ARCHIVE_NAME;
/* Size of initial mapping window, optimal if large enough to
cover the header plus the initial locale. */
@@ -46,7 +46,7 @@
#include "../locarchive.h"
#include <programs/xmalloc.h>
-#define ARCHIVE_NAME COMPLOCALEDIR "/locale-archive"
+#define ARCHIVE_NAME COMPLOCALEDIR "/" LOCALE_ARCHIVE_NAME
/* If set print the name of the category. */
static int show_category_name;
@@ -57,7 +57,7 @@
extern const char *output_prefix;
-#define ARCHIVE_NAME COMPLOCALEDIR "/locale-archive"
+#define ARCHIVE_NAME COMPLOCALEDIR "/" LOCALE_ARCHIVE_NAME
static const char *locnames[] =
{
@@ -131,6 +131,14 @@ that the objects in @file{libc_nonshared.a} are compiled with this flag
(although this will not affect the generated code in this particular
case and potentially change debugging information and metadata only).
+@item --with-locale-archive-name=@var{name}
+Use @var{name} as the file name of the locale archive, and not the
+default @file{locale-archive}. Usually, the locale archive is stored
+in the directory @file{/usr/lib/locale} (for both 32-bit and 64-bit
+targets). For parallel installation of partially compatible versions
+of @theglibc{}, this option can be used to alter the name of the file
+used by glibc and by the @command{localedef} tool.
+
@c disable static doesn't work currently
@c @item --disable-static
@c Don't build static libraries. Static libraries aren't that useful these