On 29 June 2011 21:13, Andi Hellmund wrote:
> Hi Eric,
>>
>> root@eric-laptop:/home/eric/cppcookbook# strace ./a.out en_US.utf8
>>
>
> there is nothing wrong with the strace output. It doesn't show any
> abnormalities with regard to locale handling. Maybe the ltrace utility will
> reveal more ...
After "trying to access" I would expect to see it trying to access
some glibc files:
write(1, "trying to access locale en_US.ut"..., 35trying to access
locale en_US.utf8
) = 35
open("/usr/lib/locale/locale-archive", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=104993232, ...}) = 0
mmap(NULL, 104993232, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7fdbba91d000
close(4) = 0
open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=26244, ...}) = 0
mmap(NULL, 26244, PROT_READ, MAP_SHARED, 4, 0) = 0x7fdbc0d60000
close(4) = 0
write(1, "Generated locale en_US.utf8\n", 28Generated locale en_US.utf8
On my Fedora machine /usr/lib/locale/locale-archive is part of the
glibc-common RPM.
The fact it doesn't try to open that makes me think this code from
libstdc++-v3/config/locale/generic/c_locale.cc is running:
void
locale::facet::_S_create_c_locale(__c_locale& __cloc, const char* __s,
__c_locale)
{
// Currently, the generic model only supports the "C" locale.
// See http://gcc.gnu.org/ml/libstdc++/2003-02/msg00345.html
__cloc = 0;
if (strcmp(__s, "C"))
__throw_runtime_error(__N("locale::facet::_S_create_c_locale "
"name not valid"));
}
That implies eric's gcc config didn't detect the necessary support for
--enable-clocale=gnu and is using clocale=generic - the libstdc++
config.log should confirm that and show what was missing.
The generic locale doesn't support opening named locales, so it won't work.
