<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
It definitely works with LANG=en_US.UTF-8 (and other en country
variants).<br>
It definitely doesn't<b> </b>work in the zh_CN locale, as was
reported recently.<br>
The reason evidently is a dependency in the build on the output
format of the date command.<br>
<br>
Which other locales it works in, I don't know. So, I guess it makes
sense to standardize<br>
on a particular setting. The idea of setting it internally within
the build to "C" sounds attractive<br>
because forcing people to use such an outdated compatibility mode
locale<br>
seems wrong. I'm not sure how easy it is to set environment
variables in make is<br>
(as opposed to reading/using them ). I wonder why this wasn't done
before...<br>
In any case, this is a general build issue rather than being Mac
specific.<br>
<br>
By the way, I did file a bug on the LANG breakage (7151897)<br>
<br>
Thanks<br>
Michael.<br>
<br>
On 15/03/12 18:57, Stuart Marks wrote:
<blockquote cite="mid:4F623B8C.8080709@oracle.com" type="cite">I
agree, there's a larger question about LANG that needs to be asked
here.
<br>
<br>
From a pragmatic point of view, I ran into a build issue that
boiled down to the absence of LANG in my environment in certain
cases (ssh vs VNC). README-builds.html recommends setting LANG=C
for OpenSolaris and all the Linux-flavored build environments. So,
it makes sense for LANG=C to go into the Mac build instructions as
well. (README-builds.html should get updated too.) Unlike on
Linux, the consequences of LANG being unset on Mac are that the
build breaks, so Michael has added this check in the Makefile to
prevent this obvious error. I believe he was also going to file a
bug on the Mac build breaking when LANG is unset.
<br>
<br>
Now, the larger questions are, what are the valid values of LANG,
and if all the Unix-flavored build instructions recommend setting
LANG=C, why not just have the makefiles or build scripts set this
value and be done with it?
<br>
<br>
I don't know, and I don't have the expertise in the build system
to know how other LANG settings would affect the build. Perhaps
somebody else on build-dev knows. Meanwhile, we're patching things
up this way, even though it makes things a bit messier.
<br>
<br>
s'marks
<br>
<br>
<br>
On 3/15/12 10:59 AM, Mike Swingler wrote:
<br>
<blockquote type="cite">What other values are valid? UTF8? Why
would a builder ever want to change the lang?
<br>
<br>
I think the build script should define it and use it for it's
own private purposes (allowing it to be overridden) if there is
no compelling reason for an ordinary user to know/care what lang
is. I'd prefer not to clutter up the build instructions unless
you _really_ have to pass some value that is machine-specific
(like the location of the bootstrap JDK). Even then, on the Mac,
I think the build scripts should call /usr/libexec/java_home -v
1.7+ on their own, and only balk if there is not sufficient
OpenJDK installed.
<br>
<br>
Regards,
<br>
Mike Swingler
<br>
Apple Inc.
<br>
<br>
On Mar 15, 2012, at 9:43 AM, Stuart Marks wrote:
<br>
<br>
<blockquote type="cite">Looks good to me too. I've updated the
Mac build instructions on the wiki to state that LANG should
be set.
<br>
<br>
s'marks
<br>
<br>
On 3/15/12 9:30 AM, Kelly O'Hair wrote:
<br>
<blockquote type="cite">Looks fine to me.
<br>
<br>
-kto
<br>
<br>
On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote:
<br>
<br>
<blockquote type="cite">Can I get the following jdk8 change
reviewed please?
<br>
<br>
It is a simple sanity check on Mac OS X to ensure that
<br>
LANG is set in the environment. Currently, the build fails
<br>
if it's not set, but the failure is quite obscure.
<br>
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/">http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/</a>
<br>
<br>
Thanks
<br>
Michael.
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>