all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Efraim Flashner <efraim@flashner.co.il>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 67686@debbugs.gnu.org
Subject: [bug#67686] [PATCH core-updates 4/5] gnu: glibc: Install C.UTF-8 locale.
Date: Sat, 9 Dec 2023 18:33:19 +0200	[thread overview]
Message-ID: <ZXSWz-Mp3u2b3ALc@3900XT> (raw)
In-Reply-To: <87fs0dd7qr.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3171 bytes --]

On Thu, Dec 07, 2023 at 10:26:36PM +0100, Ludovic Courtès wrote:
> Ludovic Courtès <ludo@gnu.org> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> skribis:
> >
> >> +                     ;; Install the C.UTF-8 locale so there's always a UTF-8
> >> +                     ;; locale around.
> >> +                     (let* ((out (assoc-ref outputs "out"))
> >> +                            (bin (string-append out "/bin"))
> >> +                            (locale (string-append out "/lib/locale/"
> >> +                                                   ,(package-version
> >> +                                                     this-package))))
> >> +                       (mkdir-p locale)
> >> +                       (invoke (string-append bin "/localedef")
> >> +                               "--no-archive" "--prefix" locale
> >> +                               "-i" "C" "-f" "UTF-8"
> >> +                               (string-append locale "/C.UTF-8")))))
> >
> > I realize now that this cannot work when cross-compiling, because the
> > this ‘localedef’ binary is not executable on the build machine.
> >
> > I suspect libc builds an additional ‘localedef’ for the build machine
> > but I’m not sure where it is, hmm…
> 
> I was told on #glibc that (1) there’s no ‘localedef’ for the build
> machine produced during cross-compilation, and (2) that more generally,
> there’s no way to cross-build locale data, that endianness and other
> things may matter.
> 
> I suspect #2 was about the locale archive and not locale data, because
> evidence suggests that locale data is system-independent:
> 
> --8<---------------cut here---------------start------------->8---
> $ for s in aarch64-linux powerpc64le-linux armhf-linux i686-linux ; do diff -r $(guix build glibc-locales@2.35) $(guix build glibc-locales@2.35 -s "$s") && echo "$s same as x86_64-linux" ; done
> aarch64-linux same as x86_64-linux
> powerpc64le-linux same as x86_64-linux
> armhf-linux same as x86_64-linux
> i686-linux same as x86_64-linux
> $ guix describe
>   guix 6e2dd51
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 6e2dd51df5f3f51e9056dd4f2e1b036195ab3caa
> --8<---------------cut here---------------end--------------->8---
> 
> Efraim, could you check against powerpc-linux, which is the only
> big-endian target we +/- support?

I found a difference in almost every file. The tarball of the locales
was too big to attach so I've uploaded it here¹.  Looking at it in
diffoscope it looked like most of the data that looked human readable
was the same, but there was some endian switching with the other data
bits.  So without actually checking other big endian systems it looks
like we could set target #f for the locales, but for those that share
their endianness.

¹ https://flashner.co.il/~efraim/glibc-locales-2.35-powerpc-linux.tar.xz

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-12-09 16:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 10:19 [bug#67686] [PATCH core-updates 0/5] Update glibc to 2.38; make C.UTF-8 always available Ludovic Courtès
2023-12-07 10:22 ` [bug#67686] [PATCH core-updates 1/5] gnu: gcc@11: Update to 11.4.0 Ludovic Courtès
2023-12-07 20:11   ` Janneke Nieuwenhuizen
2023-12-07 21:13     ` Ludovic Courtès
2023-12-07 10:22 ` [bug#67686] [PATCH core-updates 2/5] gnu: glibc-utf8-locales: Generalize and use gexps Ludovic Courtès
2023-12-07 10:22 ` [bug#67686] [PATCH core-updates 3/5] DRAFT gnu: glibc: Update to 2.38 Ludovic Courtès
2023-12-07 10:22 ` [bug#67686] [PATCH core-updates 4/5] gnu: glibc: Install C.UTF-8 locale Ludovic Courtès
2023-12-07 10:30   ` Ludovic Courtès
2023-12-07 20:31     ` Janneke Nieuwenhuizen
2023-12-07 21:12       ` Ludovic Courtès
2023-12-07 21:26     ` Ludovic Courtès
2023-12-09 16:33       ` Efraim Flashner [this message]
2023-12-09 21:41         ` Ludovic Courtès
2023-12-10  7:24           ` Efraim Flashner
2023-12-07 10:22 ` [bug#67686] [PATCH core-updates 5/5] gnu: glibc: Ensure C.UTF-8 locale is always found Ludovic Courtès
2023-12-07 22:54 ` [bug#67686] [PATCH core-updates v2 0/7] Update glibc to 2.38; make C.UTF-8 always available Ludovic Courtès
2023-12-07 22:54   ` [bug#67686] [PATCH core-updates v2 1/7] gnu: gcc@11: Update to 11.4.0 Ludovic Courtès
2023-12-08 17:39     ` Janneke Nieuwenhuizen
2023-12-07 22:54   ` [bug#67686] [PATCH core-updates v2 2/7] gnu: glibc-utf8-locales: Generalize and use gexps Ludovic Courtès
2023-12-07 22:54   ` [bug#67686] [PATCH core-updates v2 3/7] gnu: mpfr: Update to 4.2.1 Ludovic Courtès
2023-12-07 22:54   ` [bug#67686] [PATCH core-updates v2 4/7] DRAFT gnu: glibc: Update to 2.38 Ludovic Courtès
2023-12-09 21:44     ` Ludovic Courtès
2023-12-10 10:14       ` Ludovic Courtès
2023-12-07 22:54   ` [bug#67686] [PATCH core-updates v2 5/7] gnu: glibc: Install C.UTF-8 locale Ludovic Courtès
2023-12-07 22:54   ` [bug#67686] [PATCH core-updates v2 6/7] gnu: glibc: Ensure C.UTF-8 locale is always found Ludovic Courtès
2023-12-07 22:54   ` [bug#67686] [PATCH core-updates v2 7/7] gnu: glibc: Improve handling of empty .a files Ludovic Courtès
2023-12-09 14:58   ` bug#67686: [PATCH core-updates v2 0/7] Update glibc to 2.38; make C.UTF-8 always available Ludovic Courtès
2023-12-09 16:37     ` [bug#67686] " Efraim Flashner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXSWz-Mp3u2b3ALc@3900XT \
    --to=efraim@flashner.co.il \
    --cc=67686@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.