Thanks for answering, Paul. Actually, the context is as follows: I am logging the output of
make --print-data-base --question in order to write my hierarchical structure of included makefiles into one, big makefile. It is even possible to re-run make upon this big makefile with identical results after removing some variable definitions like MAKEFLAGS, MFLAGS, MAKECMDGOALS. This helps me to profile the impact of reading many (and I mean many) small include files as opposed to just loading and parsing one big makefile. The difference in our project is a significant 6.5 seconds or so in case the hard disk read cache is empty, BTW. We will not convert everything to one makefile, but wanted to know where we lose time. Anyway, the relevant part of the captured output looks like this: English: > # Pattern-specific Variable Values > > # No pattern-specific variable values. > > # Directories > > (...) > # make/pciutils (device 29954, inode 750349): 5 files, 17 impossibilities. > # make/inotify-tools/SCCS: could not be stat'd. > # . (device 29954, inode 740347): 162 files, 68 impossibilities. > # make/libs/libavmhmac/RCS: could not be stat'd. > # make/Config.in (device 29954, inode 753850): could not be opened. German: > # Pattern-specific Variable Values > > # Keine musterspezifischen Variablenwerte. > > # Verzeichnisse > > (...) > # make/pciutils (Gerät 29954, I-Knoten (inode) 750349): 5 Dateien, 17 > Unmöglichkeiten. > # make/inotify-tools/SCCS: Konnte den Status nicht feststellen. > # . (Gerät 29954, I-Knoten (inode) 740347): 161 Dateien, 51 Unmöglichkeiten. > # make/libs/libavmhmac/RCS: Konnte den Status nicht feststellen. > # make/Config.in (Gerät 29954, I-Knoten (inode) 753850): > Konnte nicht geöffnet werden. Please check out the last line. The German message is not just a translation of the English one, but contains an additional line break. I just noticed because when I was cleaning the log from comment lines, this one was a leftover which could not be parsed when re-running make upon the big makefile (=log). So the fix seems obvious: remove the additional line break from the German message to get it in line with the original, English output. Regards -- Alexander Kriegisch Paul Smith, 17.10.2011 14:22: > On Mon, 2011-10-17 at 12:58 +0200, Alexander Kriegisch wrote: >> I am using GNU make 3.81 on Ubuntu oneiric (11.10). I noticed that the >> German error message "Konnte nicht geöffnet werden." is sometimes listed >> in my output, even if I redirect stderr to /dev/null. So obviously it >> goes to stdout. This happens for LC_ALL=de_DE@euro, but not for >> LC_ALL=C. So maybe it is a language-specific bug or the English message >> equals "" or something. Please check and fix this problem. >> >> I would be happy if you would answer to this inquiry CC to my e-mail >> address because I am not subscribed to this list. Thanks. > > Hi Alexander. Google translate shows me that this message means "Could > not be opened". > > I'm not sure what would show a message like that in GNU make. My > suspicion, personally, is that this message is not coming from GNU make > at all but rather it's being printed by a program that GNU make is > invoking. > > I would need to see the context including the full text of the error > message to know for sure. > > In any event, GNU make's i18n/l10n implementation never, ever changes > anything like whether messages are printed to stdout or stderr based on > any of the LC_* values. The only differences in behavior based on these > settings are in the output that is printed. > _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
