Bug 915629 – sys-libs/glibc-2.37-r3: locale-gen-2.23-r1: glibc build fails with USE="compile-locales"

• Status: UNCONFIRMED
• Product: Gentoo Linux

[Description Stuart Shelton 2023-10-12 10:13:27 UTC]

If `USE="compile-locales"` then `/usr/sbin/locale-gen` contains logic which runs:

```
LC_ALL=C ./ld-*.so --library-path . "${DESTDIR}"usr/bin/localedef …
```

… from within the glib build tree.  However, with sys-libs/glibc-2.37-r3, this fails to generate locales with the error:

```
/usr/sbin/locale-gen: line 313: ./ld-*.so: No such file or directory
```

… and, on inspection of the build directory, the library I assume the script is targeting is now named `./ld-linux-x86-64.so.2`, but there's also a `./ld-lsb-x86-64.so.3` symlink present pointing to the same.

This appears to be a fix for sys-apps/locale-gen:

```
--- a/locale-gen-2.23-r1.ebuild
+++ b/locale-gen-2.23-r1.ebuild
@@ -19,15 +19,19 @@ KEYWORDS="~alpha amd64 arm arm64 hppa ~i
 RDEPEND="
        app-alternatives/awk
        app-alternatives/gzip
+       >=app-shells/bash-4
        sys-apps/gentoo-functions
        sys-apps/grep
        !<sys-libs/glibc-2.37-r3
 "
-DEPEND=""
 
 src_prepare() {
        default
        eprefixify locale-gen
+
+       sed -e '/--library-path/s|\./ld-\*\.so|./ld-linux-*.so*|' \
+                       -i locale-gen ||
+               die "In-place library name correction failed: ${?}"
 }
 
 src_install() {
```

(N.B. It's not sufficient to simply add a trailing asterisk, as the symlink then causes the new C library to try to run itself, which fails)

Additionally, the sys-libs/glibc ebuild doesn't fail if locale generation breaks, even if 'compile-locales' is specified - 'run_locale_gen()' should probably propagate the result of running `locale-gen`, and the calling functions should catch that and error-out.

Finally, `locale-gen` is executed with `${root}` equal to the build destination directory `${ED}` (e.g. `/var/tmp/portage/sys-libs/glibc-2.37-r3/image` on my system), and any `locale.gen` configuration file is looked for at `${root}/etc/locale.gen`, effectively meaning that `compile-locales` builds will always have all ~491 locales built with no option to refine this list - is this intentional?  I suspect that:

```
local locale_list="${root%/}/etc/locale.gen"
```

… in `/usr/sbin/locale-gen` should read:

```
local locale_list="${EROOT}/etc/locale.gen"
```

[Comment 1 Stuart Shelton 2023-10-12 12:39:31 UTC]

* Line 8: 'glib' should read 'glibc';

* `local locale_list="${root%/}/etc/locale.gen"` is a line from sys-libs/glibc/glibc-2.37-r3.ebuild, not `/usr/sbin/locale-gen`.

[Comment 2 Joakim Tjernlund 2023-10-12 20:54:50 UTC]

> functions should catch that and error-out.
> 
> Finally, `locale-gen` is executed with `${root}` equal to the build
> destination directory `${ED}` (e.g.
> `/var/tmp/portage/sys-libs/glibc-2.37-r3/image` on my system), and any
> `locale.gen` configuration file is looked for at `${root}/etc/locale.gen`,
> effectively meaning that `compile-locales` builds will always have all ~491
> locales built with no option to refine this list - is this intentional?  I
> suspect that:
> 
> ```
> local locale_list="${root%/}/etc/locale.gen"
> ```
> 
> … in `/usr/sbin/locale-gen` should read:
> 
> ```
> local locale_list="${EROOT}/etc/locale.gen"
> ```

This feels similar to the old https://bugs.gentoo.org/785406