Locale related warning message

[Geert Janssens]

On vrijdag 19 augustus 2011, John Ralls wrote:
> On Aug 19, 2011, at 3:24 AM, Geert Janssens wrote:
> > Hi,
> > 
> > Recently I discovered a very weird warning on my test builds. When I open
> > a book with a report open, this line is printed in the trace file:
> > 
> > WARN <> Monetary thousands separator is the same as the decimal
> > separator; converting '.' to ','
> > 
> > My LC_CURRENCY is set to nl_BE.UTF-8, for which decimals are separated by
> > a ',' and thousands are separated by ' ' (a blank).
> > 
> > My first thought was some locale misconfiguration, but it's weirder than
> > that and I fail to understand what is happening. I'll give you all the
> > pieces of the puzzle I discovered so far. Perhaps someone reading this
> > with more knowledge of internationalization can explain this better.
> > 
> > And upon closer inspection it's not only a matter of a warning. Some
> > input fields are affected too. The register is fine, but for example
> > there's a number field on Preferences->Online Banking called "Commercial
> > ATM Fees treshold". With the rpm based gnucash, this shows a decimal
> > number using ',' while my own builds show the same number with a '.'. I
> > see the same thing in the mortgage druid.
> > 
> > So the warning is only one symptom and useful to determine at startup
> > already if the build will be affected by the locale bug or not.
> > 
> > The warning by the way is generated by goffice. If I don't have any tabs
> > open using goffice (certain reports only), I won't have the warning
> > printed, but still the number entry fields show the wrong separator.
> > 
> > And now it gets curious: I have also installed gnucash 2.4.7 via rpm (on
> > Fedora 14). If I run that one from the command line, the warning isn't
> > issued. But with each and every build in my development tree, the
> > warning is printed. I tried a lot of builds: trunk, 2.4.7, 2.4 just
> > before the 2.4 branch was created,... And I tried to configure exactly
> > as the rpm version was configured (with the exception of aqbanking, but
> > I can hardly imagine this would make a difference).
> > 
> > The rpm-based version applies one patch to the sources. It suppresses the
> > binreloc disabled warning message. This has no relation to the warning
> > above, it simply removes one printf from the sources.
> > 
> > My locale related settings my be a bit unusual:
> > $ locale
> > LANG=en_US.UTF-8
> > LC_CTYPE=nl_BE.UTF-8
> > LC_NUMERIC=nl_BE.UTF-8
> > LC_TIME=nl_BE.UTF-8
> > LC_COLLATE=nl_BE.UTF-8
> > LC_MONETARY=nl_BE.UTF-8
> > LC_MESSAGES=nl_BE.UTF-8
> > LC_PAPER=nl_BE.UTF-8
> > LC_NAME=nl_BE.UTF-8
> > LC_ADDRESS=nl_BE.UTF-8
> > LC_TELEPHONE=nl_BE.UTF-8
> > LC_MEASUREMENT=nl_BE.UTF-8
> > LC_IDENTIFICATION=nl_BE.UTF-8
> > LC_ALL=
> > $ echo $LANGUAGE
> > en_BE.UTF-8:en_BE:en
> > 
> > But with the exact same locale settings the rpm version runs ok, and none
> > of my builds do.
> > 
> > So I don't understand why I'm getting this. I even tried to automake,
> > configure and build with LANG and LANGUAGE set to nl_BE.UTF-8, it doesn't
> > make a difference.
> > 
> > Can anyone perhaps shed some light on this ? Or suggest ways to debug it
> > ?
> 
> Setting $LANG=en_US is a no-op, because you've set all of $LC_.* to
> nl_BE.UTF8. That doesn't have anything to do with anything, it's just an
> observation.
> 
> Might you have a separate build of libc or libintl that your gnucash builds
> are linking? A separate set of locale files?
> 
> You can set a breakpoint in core-utils/gnc-locale.c and look  at what's
> getting set for decimal and thousands separator.

Hi John,

Thanks for your reply.

Regarding $LANG=en_US, I haven't explicitly set this. It must be an artifact 
of my system configuration. It seems KDE is setting this for some reason 
because my virtual consoles show en_BE instead. Probably because English is 
not a formal Belgian language, it substitutes my en_BE setting with en_US.

I don't have  separate libc or libintl build that I know of, nor a separate 
set of locale files.

So I wanted to try your suggestion to set a breakpoint in core-utils/gnc-
locale.c

Bur for some odd reason I can't. If I issue a command to set a breakpoint on 
line 84 or the source file, gdb never returns. It seems to get stuck in its 
attempt to set the breakpoint.

I have ran into this before and I suspect it's the module code that causes 
this. At the start of the gdb session the several gnc modules aren't loaded 
yet, so probably gdb doesn't know where to set the breakpoint.

In most cases what I did to work around this is to first set a breakpoint in 
gnucash-bin.c right after all modules got loaded (line 708). Once that line is 
reached, I can usually set breakpoints in the loaded modules.

But for core-utils this still doesn't work. Any idea why ?


Geert