From: "Ludovic Courtès" <ludo@gnu.org>
To: Tomas Volf <~@wolfsden.cz>
Cc: 67044@debbugs.gnu.org, 67686@debbugs.gnu.org
Subject: bug#67044: [bug#67686] bug#67044: C.utf8 locale cannot be built
Date: Sat, 09 Dec 2023 15:46:58 +0100 [thread overview]
Message-ID: <87a5qj5t7h.fsf@gnu.org> (raw)
In-Reply-To: <ZXJCpL0u0UoEb8YA@ws> (Tomas Volf's message of "Thu, 7 Dec 2023 23:09:40 +0100")
Hi Tomas,
Tomas Volf <~@wolfsden.cz> skribis:
>> (glibc-2.35)[arguments]: Delete ‘install-utf8-c-locale’ phase.
>
> I do think 2.35 should install the locale as well. That would require to change
>
> (invoke (string-append bin "/localedef")
> "--no-archive" "--prefix" locale
> "-i" "C" "-f" "UTF-8"
> (string-append locale "/C.UTF-8")))))
>
> into
>
> (invoke (string-append bin "/localedef")
> "-c" "--no-archive" "--prefix" locale
> "-i" "C" "-f" "UTF-8"
> (string-append locale "/C.UTF-8")))))
>
> however I think that is fine. I am using locale built like that and it works
> well. What is more, from the discussion under the other issue[0], that is
> exactly what is done during normal glibc build:
>
>> It turns out we ignore errors during the glibc build (--quiet -c).
>
> After that the drop of 'install-utf8-c-locale can be moved into some other
> version < 2.35.
I’m a bit wary of using ‘-c’ (aka. ‘--force’) unconditionally as this
could hide real problems.
But more importantly, I think it won’t matter whether glibc 2.35 ships
C.UTF-8 since it’s no longer going to be used, except for building old
locale data via ‘locale-libcs’.
> 2.
>
> I still believe it makes sense to add the -c also into the locale builder,
> because my understanding is that this change will not allow using (locale
> "C.utf8") in the operating-system definition (since that would still try to
> build it, and fail).
>
> If you are not opposed to the idea, I can send a patch if you would prefer not
> to do it yourself.
No you’re right, we could add ‘-c’ to the code in (gnu system locale),
though perhaps it would be safer to do so only in the 2.35 + C.UTF-8
case.
(We can do that independently of this patch.)
> 3.
>
>> I suspect libc builds an additional ‘localedef’ for the build machine but I’m
>> not sure where it is, hmm…
>
> I looked around a bit, and I am not sure that is true.
In the meantime I found that this is wrong indeed:
https://issues.guix.gnu.org/67686#11
Thanks for your feedback!
Ludo’.
next prev parent reply other threads:[~2023-12-09 14:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 14:42 bug#67044: C.utf8 locale cannot be built Tomas Volf
2023-11-27 22:02 ` Ludovic Courtès
2023-11-28 1:22 ` Tomas Volf
2023-12-07 10:27 ` Ludovic Courtès
2023-12-07 22:09 ` [bug#67686] " Tomas Volf
2023-12-09 14:46 ` Ludovic Courtès [this message]
2023-12-10 0:57 ` bug#67044: " Tomas Volf
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=87a5qj5t7h.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=67044@debbugs.gnu.org \
--cc=67686@debbugs.gnu.org \
--cc=~@wolfsden.cz \
/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.