locale: Make the file name of the locale archive configurable
diff mbox series

Message ID 87k1e131uq.fsf@oldenburg2.str.redhat.com
State New
Headers show
Series
  • locale: Make the file name of the locale archive configurable
Related show

Commit Message

Florian Weimer June 4, 2019, 1:40 p.m. UTC
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

Yann Droneaud June 4, 2019, 5:35 p.m. UTC | #1
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.
Carlos O'Donell June 4, 2019, 6:05 p.m. UTC | #2
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.
Florian Weimer June 5, 2019, 7:24 a.m. UTC | #3
* 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
Rafal Luzynski June 6, 2019, 10:12 p.m. UTC | #4
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
Carlos O'Donell June 7, 2019, 12:22 a.m. UTC | #5
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).
Rafal Luzynski June 7, 2019, 10:42 a.m. UTC | #6
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
Carlos O'Donell June 7, 2019, 12:32 p.m. UTC | #7
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.
Joseph Myers June 10, 2019, 3:27 p.m. UTC | #8
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).

Patch
diff mbox series

diff --git a/INSTALL b/INSTALL
index e137a71169..0244b0aa96 100644
--- a/INSTALL
+++ b/INSTALL
@@ -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
diff --git a/config.h.in b/config.h.in
index 824dfe8d8c..7d263447ed 100644
--- a/config.h.in
+++ b/config.h.in
@@ -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
+
 /*
  */
 
diff --git a/config.make.in b/config.make.in
index 2fed3da773..a6421039eb 100644
--- a/config.make.in
+++ b/config.make.in
@@ -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@
diff --git a/configure b/configure
index c773c487b5..0d9645c389 100755
--- a/configure
+++ b/configure
@@ -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 :
diff --git a/configure.ac b/configure.ac
index 598ba6c4ae..1b33559103 100644
--- a/configure.ac
+++ b/configure.ac
@@ -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],
diff --git a/locale/loadarchive.c b/locale/loadarchive.c
index 803c1cf2a4..834f794abf 100644
--- a/locale/loadarchive.c
+++ b/locale/loadarchive.c
@@ -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.  */
diff --git a/locale/programs/locale.c b/locale/programs/locale.c
index 6eae3175bb..be8f07b20f 100644
--- a/locale/programs/locale.c
+++ b/locale/programs/locale.c
@@ -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;
diff --git a/locale/programs/locarchive.c b/locale/programs/locarchive.c
index e6310b18be..02f44f6824 100644
--- a/locale/programs/locarchive.c
+++ b/locale/programs/locarchive.c
@@ -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[] =
   {
diff --git a/manual/install.texi b/manual/install.texi
index 29f6b68e25..19e1f9ca16 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -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