tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Trouble setting LC_CTYPE in a pared down chroot



Martin wrote:
> Check if you have set LC_CTYPE explicitly to "C".

Hi Martin, unfortunately that wasn't it.  LC_CTYPE wasn't previously
defined and I double-checked by setting "-i" option of env which
ensures all other environment variables are ignored.

David wrote:
> As a general quick debugging aid that may help in this case - try
> ktracing a working vs not version and compare "kdump | grep -A1 NAMI"

Paul Goyette had suggested something similarly in private.  We have a winner!

localhost# kdump /tmp/ktrace.out | grep "NAMI"
 28085      1 ktrace   NAMI  "/usr/bin/locale"
 28085      1 ktrace   NAMI  "/usr/libexec/ld.elf_so"
 28085      1 locale   NAMI  "/etc/ld.so.conf"
 28085      1 locale   NAMI  "/usr/lib/libc.so.12"
 28085      1 locale   NAMI  "/etc/malloc.conf"
 28085      1 locale   NAMI  "/usr/share/locale/en_US.UTF-8/LC_CTYPE"
 28085      1 locale   NAMI  "/usr/lib/i18n"
 28085      1 locale   NAMI  "/usr/lib/i18n/libUTF8.so.5.0"
 28085      1 locale   NAMI  "/usr/share/locale/en_US.UTF-8/LC_MONETARY"
 28085      1 locale   NAMI  "/usr/share/locale/en_US.UTF-8/LC_NUMERIC"
 28085      1 locale   NAMI  "/usr/share/locale/en_US.UTF-8/LC_TIME"
 28085      1 locale   NAMI
"/usr/share/locale/en_US.UTF-8/LC_MESSAGES/SYS_LC_MESSAGES"

Once I put /usr/lib/i18n/libUTF8.so.5.0 in the system root, LC_CTYPE
was set as expected.
Someone should probably update setlocale.3 CTYPE to mention
/usr/lib/i18n library is utilized, and remove the reference to
"setrunelocale()" which seems to be obsolete by more than a decade(?).
Thanks, everyone!
John

On Tue, Oct 19, 2021 at 10:54 AM David Brownlee <abs%absd.org@localhost> wrote:
>
> On Tue, 19 Oct 2021 at 14:54, John Marino (NetBSD) <netbsd%marino.st@localhost> wrote:
> >
> > I've put together a system root based on a minimalist subset of the
> > NetBSD 9.2/AMD64 release.  It's working fine except for one small
> > problem with locales.
> >
> > These are the complete contents of /usr/share/locale in that system root:
> > usr/share/locale/en_US.UTF-8/LC_MONETARY
> > usr/share/locale/en_US.UTF-8/LC_NUMERIC
> > usr/share/locale/en_US.UTF-8/LC_TIME
> > usr/share/locale/en_US.UTF-8/LC_MESSAGES/SYS_LC_MESSAGES
> > usr/share/locale/en_US.UTF-8/LC_CTYPE
> >
> > This is the result of the attempt to set to the en_US.UTF-8 locale:
> >
> > # env LANG=en_US.UTF-8 ./locale
> > LANG="en_US.UTF-8"
> > LC_CTYPE="C"
> > LC_COLLATE="C"
> > LC_TIME="en_US.UTF-8"
> > LC_NUMERIC="en_US.UTF-8"
> > LC_MONETARY="en_US.UTF-8"
> > LC_MESSAGES="en_US.UTF-8"
> > LC_ALL=""
> >
> >
> > The LC_COLLATE being left at the C locale is normal, I believe.
> > However, the loading of LC_CTYPE is failing silently.  I've tried
> > going through the source.  I'm sure it's some file that needs copying
> > into the system root, but I can't figure out which file that is.  It
> > doesn't appear to be documented.  The LC_CTYPE appears to have a
> > different mechanism (runes) for loading than the other categories.
> >
> > Is there anyone really familiar with the NetBSD locale system that
> > knows why LC_CTYPE is being ignored inside the chroot?  I've spent a
> > lot of time on this, so it's probably time for me to ask for some help
> > here.
>
> As a general quick debugging aid that may help in this case - try
> ktracing a working vs not version and compare "kdump | grep -A1 NAMI"
> for each :)
>
> David


Home | Main Index | Thread Index | Old Index