Re: [Xen-devel] compiling error "xen-unstable.hg"

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.07.12 at 22:29, Tim Deegan <tim@xxxxxxx> wrote:
> At 12:58 +0200 on 27 Jul (1343393923), Juergen Gross wrote:
>> Am 27.07.2012 12:38, schrieb Jan Beulich:
>> >>>>On 27.07.12 at 12:25, Ian Campbell<Ian.Campbell@xxxxxxxxxx>  wrote:
>> >>On Fri, 2012-07-27 at 11:14 +0100, Jan Beulich wrote:
>> >>>The resulting string is correct, and the grep simply doesn't work
>> >>>because you have a localized gcc. The addition of grep here was
>> >>>done to support clang (see c/s 22985:d8ea33e7af7e, author
>> >>>Cc-ed). It's not clear to me how to get around such translation
>> >>>issues
>> >>
>> >>A judicious sprinkling of LANG=C  or LC_ALL=C etc?
>> >
>> >Yuriy, could you give this a try?
>> >
>> >>>  (Tim - could you explain what output clang generates that
>> >>>made the use of grep necessary?), nor do I have a clue why the
>> >>>sed invocation would complain about an unfinished command
> 
> clang -v prints something like this:
> 
> Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> 
> so unlike GCC you can't just take the last line of the output.  Grepping
> for version was intended to get rid of the other chatter, but clearly
> it's broken in the face of localized version strings.  
> 
> We might do better to switch to '$(CC) --version | head -1', which seems
> to provide something sensible on all the gcc and clang binaries I have
> handy. 

The question is how relevant that string is in the first place:
My cross compilers, for example, get invoked through a shell
scripts that's named gccx. Invoking that with --version
reproduces the shell script name (which the script forces as
the argv[0] of the exec-ed "real" gcc):

gccx (GCC) 4.7.1

which isn't the case for -v:

gcc version 4.7.1 (GCC)

So as long as no deeper meaning is implied from the string by
anyone (there's nothing in-tree that I'm aware of), I think
that's at least as good a change as adding LC_ALL=C (of
which I'm not really certain whether it would be fully reliable
in all possible cases).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel