newlib only supports the C locale.
More specifically it completely ignores
the value of decimal point in all xxprintf
functions.
This is undesirable behaviour for places
where numeric conventions differ from those
in the USA, e.g. large parts of Europe
use a comma as decimal point.
Also this causes a bug in GTK/GLIB.
Logged In: YES
user_id=15438
Newlib is a package used by MSYS. MSYS is not in the
business of providing Newlib as a package for general use.
MSYS' purpose is to provide a minimal POSIX/Bourne
environment as a self hosted MINGW32 target. If you wish to
enhance Newlib, then you need to do so at
newlib@sources.redhat.com. If you wish MSYS to use new
features provided by newer versions of Newlib, then you must
supply the appropriate patches to update MSYS and they will
be considered. Looking forward to reviewing your patches to
MSYS.
Logged In: YES
user_id=698186
This makes MinGW at the moment unsuitable for all GTK
based applications. I know for certain that it
breaks the GTK spin-buttons and I would not be
surprised if it caused serious problems in other
parts of GTK.
Newlib was originally written for embedded systems
and for such systems it may be acceptable to have
only limited locale support. For Windows this
is not acceptable for a large group of users.
Also it seems that the current set of functions
is not consistent. I wrote a small test program
with GLib. This program called localeconv that
correctly gave the value from the global locale,
i.e. a "," as decimal point. So it seems that
it was not using the localeconv from newlib
because that one can only return values from
the "C" locale. When the rest of the library
does not support other locales than "C" it
should at least be consistent.
Logged In: YES
user_id=15438
I'm not familiar with GTK to the point of using it but from
what I understand, newlib isn't used for the Win32 port.
Earnie.
Logged In: YES
user_id=698186
GTK (actually GLib) calls vprintf or vaprintf from the
"standard" C library. I wrote a small test program
that called the relevant function g_strdup_printf
in GLib and it clearly ignored the global locale.
As I understood, newlib is the standard C library
for MinGW, so I assumed that this was the cause of
that problem.
Actually, I don't fully understand the role of
newlib in this case. The localeconv that my program
linked with was apparently not the one from newlib,
perhaps it came from msvc.dll? On the other hand
the vprintf functions that were used by the GLib dll
are locale insensitive so it is possible that those
are from newlib.
Logged In: YES
user_id=15438
The C runtime library used by MinGW is MSVCRT.DLL. We have
extended it somewhat with a mingwex library to help support
C99 compatibility and other extra features we have found
nice. But print functionality comes from MS. You will find
other ``Bugs'' listed here and in the mingw-users list that
are features of MSVCRT. You can even find replacement
functions which is probably going to be your only course of
action.
Earnie.
Logged In: YES
user_id=30442
I don't use GTK but the claim that MinGW is "unsuitable for all
GTK based applications" sounds highly exaggerated, because
GIMP can be built using MinGW. As Earnie said, newlib has
nothing to do with MinGW. If you need further advice you
might try asking on a GTK forum because plenty of people
have had success with using MinGW.