GNU bug report logs - #67686
[PATCH core-updates 0/5] Update glibc to 2.38; make C.UTF-8 always available

Previous Next

Full log

Message #79 received at 67686 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 67686 <at> debbugs.gnu.org
Subject: Re: [bug#67686] [PATCH core-updates 4/5] gnu: glibc: Install C.UTF-8
 locale.
Date: Sat, 9 Dec 2023 18:33:19 +0200

[Message part 1 (text/plain, inline)]

On Thu, Dec 07, 2023 at 10:26:36PM +0100, Ludovic Courtès wrote:
> Ludovic Courtès <ludo <at> gnu.org> skribis:
> 
> > Ludovic Courtès <ludo <at> 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 <at> 2.35) $(guix build glibc-locales <at> 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 <at> 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

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.