$ touch a.cc $ LANG=C g++ -E a.cc # 1 "a.cc" # 1 "<built-in>" # 1 "<command line>" # 1 "a.cc" $ LANG=de_DE g++ -E a.cc # 1 "a.cc" # 1 "<eingebaut>" # 1 "<Kommandozeile>" # 1 "a.cc" IMHO, preprocessor output should be independend of LANG settings. This prevents ccache (http://ccache.samba.org) from working for different users using different LANG settings. A workaround for my problem is to set LANG always to "C". But then you can't see translated errors/warnings.
This seems reasonable enough to me, offhand. I suppose <built-in> and <command line> are translated because they may be visible as part of error reporting, but this doesn't seem super compelling to me. I think the fix for this is a couple of minor changes in gcc/c-opts.c. I will submit it a bit later to see what other gcc developers think.
Subject: Bug number PR preprocessor/19753 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01851.html
(In reply to patchapp@dberlin.org from comment #2) > Subject: Bug number PR preprocessor/19753 > > A patch for this bug has been added to the patch tracker. > The mailing list url for the patch is > http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01851.html Do you know if it still applies/works?
Since then gcc/c-opts.c has been moved to gcc/c-family/c-opts.c which still uses _("<built-in>" and _("<command-line>"). Note that there is also _("<anonymous>") used in some files. All probably shouldn't be translated, since they also end up in the DWARF output.