This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Req: Disable I18N/L10N translation for gcc -print-search-dirs output.
- From: ishikawa at yk dot rim dot or dot jp
- To: gcc at gcc dot gnu dot org
- Cc: ishikawa at yk dot rim dot or dot jp
- Date: Sun, 29 Jun 2003 03:45:30 +0900 (JST)
- Subject: Req: Disable I18N/L10N translation for gcc -print-search-dirs output.
(This is a comment after running
gcc 3.3 on Debian GNU/Linux for a while.)
Request: Disable I18N/L10N translation for gcc -print-search-dirs output.
Please don't change the output of
gcc -print-search-dirs
depending on the LC_ALL environment variable setting.
That is, keep the output from the modification done
by I18N/L10N scheme.
Reason:
gcc -print-search-dirs
prints out the default directories (such as for searching
headers, binary loading, library search), and
is often further processed by other programs/scripts.
(It is more likely to be processed by other programs
than to be read by humans.)
Somewhat unexpected alteraration of the output done
by the I18N/L10N causes a problem for existing
scripts, etc..
Since the output is rather straightfoward and
understandable without I18N/L10N translation,
the demerits outweighs the merit of I18N/L10N
translation of the "gcc -print-search-dirs" output.
Background.
Here is a quote I wrote for a discussion of
a problem in compiling LM_SENSORS (cvs version).
htt[p
bss--- begin quote ---
Now there is a hitch with the internationalization (I18N)/
localization (L10N) of GCC command itself. Some messages from GCC are
now translated into local languages.
In particular, the normal output of
gcc -print-search-dirs
get slightly modified depending on the setting of environment variable
LC_ALL (and possibly LANG as well) (!).
Case in point.
Under the standard C locale, this is what we get.
ishikawa@duron$ export LC_ALL=C LANG=C
ishikawa@duron$ gcc -print-search-dirs
install: /usr/lib/gcc-lib/i386-linux/3.3/
programs: =/usr/lib/gcc-lib/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/:/usr/lib/gcc/i386-linux/3.3/:/usr/lib/gcc/i386-linux/:/usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/bin/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/bin/
libraries: =/usr/lib/gcc-lib/i386-linux/3.3/:/usr/lib/gcc/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/lib/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/lib/:/usr/lib/gcc-lib/i386-linux/3.3/../../../i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/../../../:/lib/i386-linux/3.3/:/lib/:/usr/lib/i386-linux/3.3/:/usr/lib/
Now comes the interesting part.
Under Japanese locale, here is what
we get. (I modify a few strings since I know many e-mail readers
mangle Japanese characters.)
ishikawa@duron$ export LC_ALL=ja_JP.ujis LANG=ja_JP.ujis
ishikawa@duron$ gcc -print-search-dirs
[[Install]]: /usr/lib/gcc-lib/i386-linux/3.3/
[[Program]]: =/usr/lib/gcc-lib/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/:/usr/lib/gcc/i386-linux/3.3/:/usr/lib/gcc/i386-linux/:/usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/bin/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/bin/
[[Library]]: =/usr/lib/gcc-lib/i386-linux/3.3/:/usr/lib/gcc/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/lib/i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/../../../../i386-linux/lib/:/usr/lib/gcc-lib/i386-linux/3.3/../../../i386-linux/3.3/:/usr/lib/gcc-lib/i386-linux/3.3/../../../:/lib/i386-linux/3.3/:/lib/:/usr/lib/i386-linux/3.3/:/usr/lib/
ishikawa@duron$
Actually in the above, I rewrote the three strings that come before the ":"
into ASCII strings since many won't be able to read them.
[[Install]] ... Originally, it was a non-ascii Japanese
character string that stands for `install'.
[[Program]] ... A non-ascii Japanese character string that stands
for `program'.
[[Library]] ... A non-ascii Japanese character string that stands
for `library'.
(Please note that there a few variations of
Japanese locale, especially the choice of character coding system,
and the above setting is a particular
setup I use under Debian GNU/Linux. LC_ALL=ja_JP.euc / LC_ALL=ja_JP.sjis /
LC_ALL=japanese are what I have observed on other unices.
So if you talk to other Japanese developers, you will find that
they may use slightly different locale settings).
--- end quote ---
So, why is this a problem?
There was a script to expect the string literal 'install' in the
output of "gcc -print-search-dirs" and not having it
in the output under Japanese locale caused miscompilation of
i2c modules necessary for lm_sensor package.
(If I am not mistaken,
many embedded embedded programming folks, who use GCC under
cross compiler setting depend on this feature very much (in order
to properly handling variouhs header files under cross / mixed
setting. Yes, some people have accumulated
various header files such as under /usr/local/include
and we often have to disable the inclusion using
-nostdinc, and yet want to process the system supplied
headers AFTER our own headers. (-print-search-dirs is
a way to look for the standard header directory.)
Many scripts depending on the output have been written.
I know that some people may prefer alteration by I18N/L10N scheme
for various output from GCC, but
this particular output from
"gcc -print-search-dirs"
should be excluded from such alteration IMHO.
[end of memo]