| Summary: | Upgrade from glibc 2.26 to 2.27 broke some locales (ru_RU in particular) | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | hoxnox <psycho_dk> |
| Component: | Other | Assignee: | romain.naour |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | buildroot |
| Priority: | P4 | ||
| Version: | 2018.05 | ||
| Target Milestone: | 2019.05 | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | Www.naourjamesbug.in | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | glibc downgrade patch | ||
|
Description
hoxnox
2018-06-12 14:53:47 UTC
Hi, Are you sure that Buildroot is using localedef from the host? Buildroot is building it's own localedef version from [1] which is probably too old for glibc 2.27. Maybe we have to bump localedef to [2] which is used by Yocto? localedef is build by the glibc package but for the target, so we really need to build it outside of glibc package. Best regards, Romain [1] http://www.pengutronix.de/software/ptxdist/temporary-src/localedef-eglibc-2.14.1-r17443-ptx1.tar.bz2 [2] git://github.com/kraj/localedef Hi, So, we really have a problem with host-localedef... Our current version is outdated (based on eglibc) and doesn't work with glibc 2.26. Localedef package version should be the same as glibc package because localedef program is part of glibc and building it require glibc sources. Yocto and ptxdist maintain some "hack/workaround" to only build localedef for the host [1] [2]. Also, pre compiled toolchain doesn't provide localdef binary for the host along with glibc provided for the target. I'm not sure if we should allow using BR2_GENERATE_LOCALE for external toolchains since there is no guaranties that localedef is compatible with toolchain locale. Best regards, Romain [1] https://git.pengutronix.de/cgit/ptxdist/tree/patches/localedef-glibc-2.27/0001-HACK-only-build-and-install-localedef.patch [2] git://github.com/kraj/localedef and http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-core/glibc/cross-localedef-native_2.26.bb?id=rocko-18.0.3 An initial proposal has been made to resolve this issue: https://patchwork.ozlabs.org/patch/950717/. While the patch is not perfect, it shouldn't be too difficult to improve to make it acceptable. |