Steve Crawford <scrawford@pinpointresearch.com> writes:
> Summary:
> I installed glibc-locale and initdb now works fine.
Interesting. I had just come to the conclusion that you were missing
some files from this part of your strace:
[pid 5240] open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/share/locale/locale.alias", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/lib/locale/en/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/lib/locale/en_US/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/lib/locale/en/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory)
The references to "/usr/lib/locale/en/" look to be fallback attempts,
but on my Fedora machine, the other four files all exist and are in
the glibc-common RPM, which means that it's pretty much impossible not
to have them installed. I wasn't aware that other distros package them
as optional, but now we know.
> I'll leave it to the development-team to decide if this situation should
> be classed as a bug, a failure of the installation routines to detect
> the absence of necessary files, a need for a better error message or
> simply failure of the nut behind the wheel.
The problem is that all we see is a failure return from setlocale(),
and there's no API defined to find out *why* it failed; the presumption
is always that it's the user's fault, ie, the given locale string is
just wrong.
It might be possible to struggle along with the assumption that the
locale is really C, but I'm not sure what else might break if we try.
regards, tom lane
