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]

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]


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