| Message ID | 87k1e131uq.fsf@oldenburg2.str.redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | locale: Make the file name of the locale archive configurable | expand |
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).
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