insufficient fix for gcc localised output in stubdom makefile

insufficient fix for gcc localised output in stubdom makefile

[Guillaume Rousse]

Hello.

There was a slight change in stubdom makefile from 3.3 to 3.3.1, in 
order to use non-localised gcc output:
GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 
's/install: \(.*\)/\1/p')

However, this is still unsuffient to just set LANG:
[guillomovitch@n2 xen]$ LANG=C gcc -print-search-dirs | sed -n -e 
's/install: \(.*\)/\1/p'

At least on our build system, you have to export LC_ALL instead:
[guillomovitch@n2 xen]$ LC_ALL=C gcc -print-search-dirs | sed -n -e 
's/install: \(.*\)/\1/p'
/usr/lib/gcc/i586-manbo-linux-gnu/4.3.2/
-- 
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Ile de France
Tel: 01 69 35 69 62

Re: insufficient fix for gcc localised output in stubdom makefile

[Ian Jackson]

Guillaume Rousse writes ("[Xen-devel] insufficient fix for gcc localised output in stubdom makefile"):
> There was a slight change in stubdom makefile from 3.3 to 3.3.1, in 
> order to use non-localised gcc output:
> GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 
> 's/install: \(.*\)/\1/p')

This is a joke, right ?  The purpose of  gcc -print-search-dirs
is to provide information to other programs.  Its output should not be
localised.

If it is, then that is a bug in your compiler.  As a workaround, set
whatever environment variables are necessary to make it not be so
stupid.

Alternatively, can I complain that your email program does not
understand emails where I have translated the names of the headers
into Dutch ?  Should Germans file bugs against Xen, complaining that
they have to write the keywords in the xmdomain.cfg files in English ?

What about translating the name of gcc ?  Surely it should be called
something else in French.  La Collection des Transcodeurs GNU aka
/usr/bin/ctg ?  You'll have to help me here, as my French is rather
rusty.

Ian.

Re: insufficient fix for gcc localised output in stubdom makefile

[Guillaume Rousse]

Ian Jackson a écrit :
> Guillaume Rousse writes ("[Xen-devel] insufficient fix for gcc localised output in stubdom makefile"):
>> There was a slight change in stubdom makefile from 3.3 to 3.3.1, in 
>> order to use non-localised gcc output:
>> GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 
>> 's/install: \(.*\)/\1/p')
> 
> This is a joke, right ?  The purpose of  gcc -print-search-dirs
> is to provide information to other programs.  Its output should not be
> localised.
> 
> If it is, then that is a bug in your compiler.  As a workaround, set
> whatever environment variables are necessary to make it not be so
> stupid.
Well, that's not really new apparently:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14351

My point here is not to discuss if this is a bug or not, rather than the 
workaround used in xen makefile is not enough for everyone out there.

Re: insufficient fix for gcc localised output in stubdom makefile

[Ian Jackson]

Guillaume Rousse writes ("Re: [Xen-devel] insufficient fix for gcc localised output in stubdom makefile"):
> Well, that's not really new apparently:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14351

Yes, I came across that.

> My point here is not to discuss if this is a bug or not, rather than the 
> workaround used in xen makefile is not enough for everyone out there.

If it would make things tidier I'd be happy to submit a patch to
remove this absurd (and incorrect) workaround from the Xen makefiles.

Ian.

Re: insufficient fix for gcc localised output in stubdom makefile

[Guillaume Rousse]

Ian Jackson a écrit :
>> My point here is not to discuss if this is a bug or not, rather than the 
>> workaround used in xen makefile is not enough for everyone out there.
> 
> If it would make things tidier I'd be happy to submit a patch to
> remove this absurd (and incorrect) workaround from the Xen makefiles.
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/xen/current/SOURCES/xen-3.3.1-fix-stubdom-Makefile.patch?view=markup
But it doesn't really remove the workaround, rather extend it :)

-- 
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université, 4 rue J. Monod
91893 Orsay Cedex France
Tel: 01 69 35 69 62