[PATCH FOR REVIEW]: Unset JAVA_HOME and JDK_HOME prior to building OpenJDK

Andrew John Hughes gnu_andrew at member.fsf.org
Wed Aug 26 14:00:59 PDT 2009

2009/8/26 Mark Wielaard <mark at klomp.org>:
> On Wed, 2009-08-26 at 19:57 +0100, Andrew John Hughes wrote:
>> 2009/8/25 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>> > 2009/8/25 Mark Wielaard <mark at klomp.org>:
>> >> On Tue, 2009-08-25 at 09:29 -0400, Lillian Angel wrote:
>> >>> Andrew John Hughes wrote:
>> >>> > This simple patch for IcedTea6 unsets JAVA_HOME and JDK_HOME before
>> >>> > starting an OpenJDK build.  If JAVA_HOME is set, an OpenJDK build will
>> >>> > fail.
>> >>> >
>> >>> > Ok to commit?
>> >>> >
>> >>> > ChangeLog:
>> >>> >
>> >>> > 2009-08-25  Andrew John Hughes  <ahughes at redhat.com>
>> >>> >
>> >>> >         * Makefile.am:
>> >>> >         Unset JAVA_HOME and JDK_HOME before building.
>> >>>
>> >>> I am not thrilled with the idea of unsetting env vars on a system. I
>> >>> think maybe it would be better for configure to fail and give an error
>> >>> message if either of these are set.
>> >>
>> >> Why does the build fail if any of these are set in the first place?
>> >
>> > Because Sun designed it to do so. Clearly you don't have JAVA_HOME set
>> > by default on your system (some distros do this) or you would have had
>> > the fun of the OpenJDK build failing.
>> > See: http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#linux
>> >
>> >> I agree that in general it is better to have configure figure out
>> >> settings. That is really what it is for.
>> >>
>> >> The GNU Make manual actually warns not to rely on environment variables:
>> >>
>> >>        It is not wise for makefiles to depend for their functioning on
>> >>        environment variables set up outside their control, since this
>> >>        would cause different users to get different results from the
>> >>        same makefile. This is against the whole purpose of most
>> >>        makefiles.
>> >>        http://www.gnu.org/software/automake/manual/make/Environment.html
>> >>
>> > Unfortunately, that is how the entire OpenJDK build works.  We already
>> > set 30-40 variables in Makefile.am.
>> >
>> So can I push this or not?  FWIW, IcedTea7 already has this change and
>> I've not experienced any problems or loss of JAVAC settings with it
>> applied.
> I might think it is ugly, but it does seem harmless, so if it helps then
> please do. But it would be good to know what exactly uses JAVA_HOME
> during the build if it is set.
> Cheers,
> Mark

The OpenJDK build crashes out straight away if JAVA_HOME is set.
Grepping through the source code, it seems parts of the HotSpot build
rely on it, including test_gamma which uses JAVA_HOME to find the
location of its libraries.  I'm guessing it will introduce the kind of
issues we see with Ant in that another JDK (specified by JAVA_HOME) is
being used during the build, and causes problems in some cases.  I can
remove the Makefile code that causes the build to stop and see what
happens, but I'm guessing there will be corner cases we won't
immediately spot.  The HotSpot build seems to set JAVA_HOME itself so
one would hope this always arrives the env setting, but there must be
a reason Sun chose to blacklist this originally.

JAVAC is another case by the way.  I added a line to unset this,
because if it is set the CORBA build tries to compile using it.  As it
is missing all the flags it needs to do so, it inevitably fails to

# Invoking the Java compiler.   In leaf makefiles, choose as follows:
#  -- Use JAVAC if you want to take full control of what options get
#     passed to javac.
#  -- Use JAVAC_CMD if you want to take the defaults given to you.

I don't know if any other distros do so, but Gentoo sets JAVAC to just
the path of the javac binary, which is not enough to build.
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

More information about the distro-pkg-dev mailing list