2009/11/17 Kurt Miller <k...@intricatesoftware.com>:
> Hi Greg,
>
> Greg Lewis wrote:
>> G'day all,
>>
>> I just committed a few patches for Zero support on BSD which should be
>> fairly safe. I've got a couple more that I'd like to get some review
>> on before committing. So far I've tested them on FreeBSD 7.x/i386 (single
>> processor machine) and I'm able to run a few simple Java programmes with
>> the resulting JDK:
>>
>>> ./build/bsd-i586/bin/java -version
>> openjdk version "1.7.0-internal"
>> OpenJDK Runtime Environment (build
>> 1.7.0-internal-glewis_2009_11_15_11_42-b00)
>> OpenJDK Zero VM (build 17.0-b05, interpreted mode)
>>
>> These are the extra settings I'm using to build Zero:
>>
>> ZERO_BUILD=true
>> ZERO_ENDIANNESS=little
>> ZERO_LIBARCH=i386
>> ZERO_ARCHDEF=IA32
>>
>> It doesn't really seem like I should have to set the latter three, but they
>> don't seem to get set otherwise for the HotSpot build. It really seems
>> like the build should run something like jdk/make/jdk_generic_profile.sh
>> which seems to set up things for Zero.
>>
>> Anyway, in terms of the patches, I'd like some opinions on whether the
>> atomic changes are portable across the different BSDs (and whether they
>> do the right thing :). Note that the changes to os_bsd_zero.cpp are fairly
>> minimal. I suspect a careful review of the file may identify more changes
>> that should be made.
>>
>> I'll include the patches inline and also attach them since I'm not sure on
>> the mailing list policy regarding attachments.
>
> I was hoping to provide feedback on these, but I currently can't build
> the tree. The corba build fails with:
>
> /bin/sh: Check_ALT_JDK_IMPORT_PATH/bin/javac: not found
>
> In the past setting ALT_BOOTDIR=/usr/local/jdk-1.6.0 was good enough
> to build the tree from scratch. Have things changed an now we need to
> keep an old 1.7 build around to point ALT_JDK_IMPORT_PATH at?
>
> I'll keep looking into what's going with my build...
>
> Regards,
> -Kurt
>
>
ALT_JDK_IMPORT_PATH isn't normally required, although a recent bug
revealed that many Sun engineers still set it.
This looks like a bug but I can't see anything that would cause it in
the differences between the BSD repository and the main OpenJDK one.
Is LANGTOOLS_DIST being set correctly?
From corba/make/common/shared/Defs-java.gmk:
# Langtools
ifdef LANGTOOLS_DIST
JAVAC_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javac.jar
JAVAH_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javah.jar
JAVADOC_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javadoc.jar
DOCLETS_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/doclets.jar
JAVAC_CMD = $(BOOT_JAVA_CMD) \
"-Xbootclasspath/p:$(JAVAC_JAR)" \
-jar $(JAVAC_JAR) $(JAVACFLAGS)
JAVAH_CMD = $(BOOT_JAVA_CMD) \
"-Xbootclasspath/p:$(JAVAH_JAR)$(CLASSPATH_SEPARATOR)$(JAVADOC_JAR)$(CLASSPATH_SEPARATOR)$(JAVAC_JAR)"
\
-jar $(JAVAH_JAR) $(JAVAHFLAGS)
JAVADOC_CMD = $(BOOT_JAVA_CMD) \
"-Xbootclasspath/p:$(JAVADOC_JAR)$(CLASSPATH_SEPARATOR)$(JAVAC_JAR)$(CLASSPATH_SEPARATOR)$(DOCLETS_JAR)"
\
\
-jar $(JAVADOC_JAR)
else
# If no explicit tools, use boot tools (add VM flags in this case)
JAVAC_CMD = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \
$(JAVACFLAGS)
JAVAH_CMD = $(JAVA_TOOLS_DIR)/javah \
$(JAVAHFLAGS)
JAVADOC_CMD = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%)
endif
You should be using the top block. The second block will result in
the error you give as JAVA_TOOLS_DIR is ALT_JDK_IMPORT_PATH.
Defs-bsd.gmk is unique to the repository and also seems to do
something with ALT_JDK_IMPORT_PATH.
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
