Skip to main content

Building JDK bits

Posted by ixmal on May 8, 2009 at 7:46 AM PDT

Recently, I got a new desktop, and the first thing I started with was building JDK. Approximately at the same time I got an image of a new operating system by Microsoft (beta version) and started testing it. So, the natural idea was to combine these efforts. Unluckily, I decided to install the 64-bit version of the system to get the most of 4Gb RAM.



Windows 7 installation went successfully, without any problems, cygwin didn't bring any unpleasant surprises as well. The next step was to install the compiler - VS 2008 Express Edition, the only available at the moment a Visual Studio product that, nevertheless, is not supported by JDK yet. I selected the 7.0a version as the Platform SDK, which also was provided by Windows 7.



Just a minor reservation: I set the environment variable INSANE to yes while building the system. This variable enables ignoring some non-critical building bugs that inevitably appear on non-supported platforms. For the other typical cases, I wouldn't modify the default value of INSANE (no or undefined).



So, the building started. A few seconds of waiting and:



  windows i586 1.7.0-internal build started



Ooops? What's up? I wanted the 64-bit building! For some reasons JDK considered my desktop 32-bit, therefore, I had to force 64-bit by specifying ARCH_DATA_MODEL=64.



Restart. This time the building process lasted a little bit longer:



  C:/PROGRA~2/MICROS~1.0/VC/bin/X86_AM~1/cl  -O1   -Zi -nologo -MD /D _STATIC_CPPLIB  -Fdc:/work/ie-build-64/tmp/java/hpi/windows_
threads/obj64/linker_md.pdb -Fmc:/work/ie-build-64/tmp/java/hpi/windows_threads/obj64/linker_md.map -wd4800 -Wp64  -W3   -DWIN32
-DIAL -D_LITTLE_ENDIAN -D_X86_ -Dx86  -DWIN32_LEAN_AND_MEAN -I. -Ic:/work/ie-build-64/tmp/java/hpi/windows_threads/CClassHeader
s -I../../../../src/windows/javavm/export -I../../../../src/share/javavm/export -I../../../../src/windows/hpi/include -I../../..
/../src/windows/hpi/export -I../../../../src/share/hpi/include -I../../../../src/share/hpi/export    -c -Foc:/work/ie-build-64/t
mp/java/hpi/windows_threads/obj64/linker_md.obj ../../../../src/windows/hpi/src/linker_md.c

cl : Command line warning D9035 : option 'Wp64' has been deprecated and will be removed in a future release

linker_md.c

C:\PROGRA~1\MICROS~1\Windows\v6.1\INCLUDE\winnt.h(128) : fatal error C1189: #error :  "No Target Architecture"

make[3]: *** [c:/work/ie-build-64/tmp/java/hpi/windows_threads/obj64/linker_md.obj] Error 2

make[3]: Leaving directory `/cygdrive/c/work/ws/ie/make/java/hpi/windows'

make[2]: *** [all] Error 1

make[2]: Leaving directory `/cygdrive/c/work/ws/ie/make/java/hpi'

make[1]: *** [all] Error 1

make[1]: Leaving directory `/cygdrive/c/work/ws/ie/make/java'

make: *** [all] Error 1



What? Wait a minute... Why -D_X86_ and -Dx86? There is something wrong... I started exploring the whole log and discovered the following:



  build windows ia64 1.7.0-internal started



But "ia64" is the Itanium architecture, not what I intended to build. Interesting, can I build JDK on Itanium? I'd better leave it to someone else to test. :) The wrong architecture problem was resolved by specifying the PROCESSOR_IDENTIFIER variable to AMD64 (this issue has been already resolved in the very latest JDK builds). Restarted again:



  C:/PROGRA~2/MICROS~1.0/VC/bin/X86_AM~1/link -dll -out:c:/work/ie-build-64/tmp/java/verify/obj64/verify.dll \
-map:c:/work/ie-build-64/tmp/java/verify/obj64/verify.map \
-nologo /opt:REF /incremental:no /manifest /debug /LIBPATH:c:/work/devtools/dxsdk9/Lib/x64 @c:/work/ie-build-64/tmp/java/verify/obj64/verify.lcf c:/work/ie-build-64/lib/jvm.lib

LINK : fatal error LNK1104: cannot open file 'c:/work/ie-build-64/lib/jvm.lib'

make[2]: *** [c:/work/ie-build-64/bin/verify.dll] Error 80

make[2]: Leaving directory `/cygdrive/c/work/ws/ie/make/java/verify'

make[1]: *** [all] Error 1

make[1]: Leaving directory `/cygdrive/c/work/ws/ie/make/java'

make: *** [all] Error 1



There is something wrong with the lib/jvm.lib file in the build directory. Is this file on the disk? It is... Well, but what is in this file? Aha, "access denied" on a preview attempt. Now I see why the linker doesn't find this file. But what is still unclear to me, why this file has such strange security permissions.



Frankly speaking, I almost stuck on this step... After one and a half day I found a brief, just a few pages, description of the CYGWIN variable. And - what a miracle! - it helped. I set its value to nontsec and made all files created by cygwin obtain permissions according to the NTFS model, not POSIX. It is stated that I might encounter the same problem on Vista as well, or may be even on XP or 2000 when using NTFS. I didn't try building on Vista, but it works fine on XP.



The next restart revealed the absence of the msvcr90.dll file in the system directory C:\Windows\System32. Unfortunately, I cannot provide the exact log for this error: for some reasons subsequent builds do not crash on this step. However, I can suggest the solution: you need to set up the following environment variable:



ALT_MSVCRNN_DLL_PATH=/redist/amd64/Microsoft.VC90.CRT



One and a half hour more - why building on Windows takes so much time? - and, voila, JDK is done. It's time to relax a little, to test, for instance, to run some demos.



  $ bin/java -showversion -jar demo/jfc/Java2D/Java2Demo.jar



  Error occurred during initialization of VM

  java/lang/NoClassDefFoundError: java/lang/Object



Well... It's not time for relaxing yet... Having thought I decided that it is because of the wrong HotSpot version I used for building. I used Visual Studio 2008 while the promoted build for HotSpot is built by using Visual Studio 2003. Therefore, let's build the virtual machine.



I have to admit that after building JDK and setting all the required variable, the process of HotSpot building went surprisingly well. Several errors related to the data structure redefinition and appeared in a new version of Platform SKD had been fixed, so all I had to do was just to get them from the hotspot space. After the build is complete, you need to take jvm.dll for server, in case of 64-bit implementation, or client with server, in case of 32-bit implementation, and copy it to the bin directory of the built JDK.



Finally, a couple of words about 32 bits. The following is a to-do list for the successful building procedure:

  • 1a. Set ARCH_DATA_MODEL=32

    or

  • 1b. Set PROCESSOR_IDENTIFIER=x86
  • 2. Set ALT_MSVCRNN_DLL_PATH=/redist/x86/Microsoft.VC90.CRT
  • 3. Use 32-bit promoted JDK build as a bootstrap.
  • 4. Add 32-bit versions of the compiler, linker, and other utilities to PATH. They are located in /bin/x86_amd64 and



My special thanks to Kelly for his help and advice.


Related Topics >>

Comments

good work

Hello, I just noticed your post about Java on Itanium and wanted to point out that an Intel Developer has been writing tips for Java programming for Itanium Itanium on our blog. Please check it out, feel free to ask questions, and distribute this link as needed those who may find it useful. http://blog.itaniumsolutions.org/author/slava-shakin/.