This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC's Unicode use [was Re: Compile performance of Linux kernels in mainline gcc]


Paul Schlie <schlie@comcast.net> writes:

> > From: "Joseph S. Myers" <joseph@codesourcery.com>
> > Any programs parsing GCC's output need to set LC_ALL=C if they care at all
> > about the text of error messages; this is nothing new as there have been
> > translated messages for a long time.  If they only care for the message
> > format "source-file:line: message" (a GNU standard, not GCC-specific) then
> > they just need to expect messages in the locale character set - and
> > translated messages again mean this has been the case for a long time.
> > 
> > There was a time when many programs adding Unicode support had their own
> > special command-line options to enable it.  This was a mistake; it made
> > things excessively difficult if you just want a working Unicode
> > environment without fiddling with every program's configuration.  Setting
> > environment variables such as LANG, LC_CTYPE and LC_ALL is the established
> > way of controlling these things for all programs, not just GCC; and unlike
> > five years ago, this works generally for most programs on a GNU/Linux
> > system, with only a small proportion that don't yet work with Unicode.
> 
> Understood, although it would seem convenient to be able to override the
> environment's local encoding preference via the command line on occasion.

In most shells, you can do that using something like this:

LANG=C gcc ....

or

env LANG=C gcc ....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]