I did a full build yesterday, and am able to run hello world and byt b24
SwinSet2 demo.
The setup: cygwin version (from uname -a) is:
CYGWIN_NT-5.1 serrano 1.5.25(0.156/4/2) 2007-12-14 19:21 i686 Cygwin
I have replaced make with version 3.80 and file with version 4.19.
In my default tcsh shell I source a file containing this:
---%<---
setenv ALT_BOOTDIR c:/apps/jdk1.6.0
setenv ALT_BINARY_PLUGS_PATH c:/sun/ws/openjdk-binary-plugs
setenv ALT_JDK_IMPORT_PATH c:/apps/jdk1.7.0
setenv ALT_DXSDK_PATH c:/sun/lib/DXSDK
setenv ALT_COMPILER_PATH c:/progra~1/micros~1.NET/vc7/bin
setenv ALT_MSDEVTOOLS_PATH c:/progra~1/micros~1.NET/common7/tools/bin
setenv ALT_MSVCR71_DLL_PATH c:/progra~1/micros~1.NET/SDK/V1.1/bin
setenv ALT_FREETYPE_LIB_PATH c:/sun/lib/freetype-i586/lib
setenv ALT_FREETYPE_HEADERS_PATH c:/sun/lib/freetype-i586/include
setenv ANT_VER 1.7.1
setenv ANT_HOME c:/apps/apache-ant-${ANT_VER}
setenv FINDBUGS_VER 1.3.1
setenv FINDBUGS_HOME c:/sun/lib/findbugs-${FINDBUGS_VER}
setenv OPENJDK true
unsetenv LD_LIBRARY_PATH
unsetenv CLASSPATH
unsetenv JAVA_HOME
unsetenv SHLVL
setenv ALT_MSVCR71_DLL_PATH ${ALT_BOOTDIR}/bin
---%<---
Then I run "bash -i" (without -i, the bash prompt doesn't appear w/in emacs),
and then:
cd c:/sun/ws/tl
. jdk/make/jdk_generic_profile.sh
make MB_OF_MEMORY=1024 fastdebug_build > fdb.log 2> fdb.err
The MB_OF_MEMORY convinces the build process that the machine has that much
memory; the default is 512.
As with Tim's attempt, I made the change to Defs-internal.gmk (see below).
The resulting build directory contains more than just fastdebug directories:
WINDOW~1-fastdebug
WINDOW~2-fastdebug
windows-i586
windows-i586-fastdebug
windows-i586-fastdebug-fastdebug
but only the windows-i586-fastdebug directory has useful bits.
Dave
Tim Bell wrote:
Ted Neward wrote:
After making the makefile change Kelly described
For those following along, the makefile change was to delete line 211 of
jdk7/make/Defs-internal.gmk:
$ pwd
/cygdrive/g/tbell/jdk7/make
$ diff -u Defs-internal.gmk.00 Defs-internal.gmk
--- Defs-internal.gmk.00 2008-02-21 13:28:56.625000000 -0800
+++ Defs-internal.gmk 2008-02-28 15:48:56.531250000 -0800
@@ -208,7 +208,6 @@
# Common make arguments (supplied to all component builds)
COMMON_BUILD_ARGUMENTS = \
- JDK_TOPDIR=$(ABS_JDK_TOPDIR) \
JDK_MAKE_SHARED_DIR=$(ABS_JDK_TOPDIR)/make/common/shared \
EXTERNALSANITYCONTROL=true \
TARGET_CLASS_VERSION=$(TARGET_CLASS_VERSION) \
After this I did a full control build from the top level:
export OPENJDK=true
export BUILD_NUMBER="b`date +%j`"
export HOTSPOT_BUILD_JOBS=4
(time make fastdebug_build COMPANY_NAME=self MB_OF_MEMORY=1000 2>&1 |
tee fastdebug_build.log)
103 minutes of wall clock time later, I was able to run javac and
HelloWorld:
$ pwd
/cygdrive/g/tbell/jdk7/build/windows-i586-fastdebug/j2sdk-image/bin
$ ./javac -g G:/tbell/jdk7/jdk/test/com/sun/jdi/HelloWorld.java
$ ./java -classpath G:/tbell/jdk7/jdk/test/com/sun/jdi HelloWorld
Hello, world!
But when I tried to use that java.exe to run SwingSet2 from the JDK7 b24
binary install:
$ ./java -jar G:/jdk1.7.0-b24/demo/jfc/SwingSet2/SwingSet2.jar
It painted the splash screen, then fell over with:
Exception in thread "main" java.lang.UnsatisfiedLinkError:
G:\tbell\jdk7\build\windows-i586-fastdebug\j2sdk-image\jre\bin\fontmanager.dll:
Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1767)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1684)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1066)
at
sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:61)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32)
at sun.font.FontManager$1.run(FontManager.java:233)
at java.security.AccessController.doPrivileged(Native Method)
at sun.font.FontManager.<clinit>(FontManager.java:230)
at
sun.java2d.SunGraphicsEnvironment$2.run(SunGraphicsEnvironment.java:178)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.java2d.SunGraphicsEnvironment.<init>(SunGraphicsEnvironment.java:162)
at
sun.awt.Win32GraphicsEnvironment.<init>(Win32GraphicsEnvironment.java:90)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:539)
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)
at javax.swing.RepaintManager.<clinit>(RepaintManager.java:199)
at javax.swing.UIManager.initialize(UIManager.java:1437)
at javax.swing.UIManager.maybeInitialize(UIManager.java:1409)
at javax.swing.UIManager.getDefaults(UIManager.java:659)
at javax.swing.UIManager.put(UIManager.java:988)
at SwingSet2.main(SwingSet2.java:226)
I will file a bug on this if I can't find a relevant bug open.
fastdebug builds to run. Specifically, if I trace execution with
windbg, I find that hpi::initialize() (called from os::init_2() in
hotspot\src\os\windows\vm\os_windows.cpp) fails for some
reason—haven’t traced it deeper than that yet. Given that my previous
build failures were with files from that same subsystem (HPI), I
thought I might see if anybody here thinks the two are related.
I am getting a lot further than HPI with my build.
Question for Ted: did you build everything, or not? If it was a partial
build, maybe there is a problem getting files copied out of the
bootstrap into where they belong.
Tim
