I'm a bit rusty at gdb, but here's what I've been able to find:
I compiled coreutils with -ggdb3 and was able to see, that the test called gl_locale_name_posix, which used my systems current setlocale (do debugging symbols):Breakpoint 5, 0x00007ffff7a582b4 in setlocale () from /usr/lib/libc.so.6(gdb) stepSingle stepping until exit from function setlocale,which has no line number information.gl_locale_name_posix (category=5, categoryname=0x4035f3 "LC_MESSAGES") at localename.c:27042704 }(gdb)gl_locale_name (category=5, categoryname=0x4035f3 "LC_MESSAGES") at localename.c:28542854 if (retval != NULL)(gdb)2855 return retval;(gdb)2858 }(gdb)test-localename.c:86: assertion 'strcmp (gl_locale_name (LC_MESSAGES, "LC_MESSAGES"), gl_locale_name_default ()) == 0' failedretval from setlocale is:(gdb) p retval$11 = 0x606f00 "en_US.UTF-8"So I'm unsure what to do next?My GNU libc version is:% pacman -Qi glibcName : glibcVersion : 2.19-5Description : GNU C LibraryArchitecture : x86_64[ ... ]Build Date : 2014-05-16T10:15:30 CESTInstall Date : 2014-05-30T16:11:30 CESTThanks,HenrikOn Sat, Jul 19, 2014 at 5:07 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Henrik Juul Pedersen wrote:Thanks, since LC_MESSAGES is supposed to be unset at that point, gl_locale_name appears to be the culprit. Can you use GDB to figure out why it's returning "en_US.UTF-8"? You may need to recompile with "gcc -O0 -g3" to get decent debugging output. Or, if you can't use GDB, just put in printf statements.
gl_locale_name(LC_MESSAGES (int 5), 'LC_MESSAGES'): en_US.UTF-8
gl_locale_name_default(): C