Skip to main content

More Building Mustang JDK with MSVC 2005 Express

21 replies [Last post]
Joined: 2003-07-15

I'd also like to compile the JDK with MSVC 2005 Express. I tried with my MSVC++ 6.0 standard (not professional) Edition, and that didn't work. I figure it will help others more to use the free compiler

Mike Atkinson is doing the same and since he's ahead of me, I'll go ahead and try not to skip compiling hotspot. I'll post problems that I hit.
I'm compiling on Windows XP Professional Version 2002 with SP2 using cygwin.

Here's my setup.bat file:
echo off
rem Root of Visual Developer Studio Common files.
set VSCommonDir=C:\PROGRA~1\MIAF9D~1\Common

rem Root of Visual Developer Studio installed files.
set MSDevDir=C:\PROGRA~1\MIAF9D~1\Common\msdev98

rem Root of Visual C++ installed files.

rem VcOsDir is used to help create either a Windows 95 or Windows NT specific pa
set VcOsDir=WIN95
if "%OS%" == "Windows_NT" set VcOsDir=WINNT

set PATH=C:\dev\cygwin\bin;C:\dev\cygwin\usr\local\bin;C:\dev\cygwin\usr\bin
set PATH=%MSDevDir%\BIN;%MSVCDir%\BIN;%VSCommonDir%\TOOLS\%VcOsDir%;%VSCommonDir

set VcOsDir=
set VSCommonDir=

set ALT_BOOTDIR=c:\\dev\\jdk1.5

set ALT_DEVTOOLS_PATH=c:\usr\bin

set ALT_DXSDK_PATH=c:\dev\dxsdk

set ALT_UNIXCOMMAND_PATH=\dev\cygwin\bin

set ALT_OUTPUTDIR=C:\dev\mustang\output
set ALT_COMPILER_PATH=C:\dev\vs8\VC\bin
set ALT_MSDEVTOOLS_PATH=C:\dev\vs8\VC\bin
REM set ALT_COMPILER_PATH=C:\Program Files\Microsoft VisualStudio\VC98\Bin
REM set ALT_MSDEVTOOLS_PATH=C:\Program Files\Microsoft VisualStudio\VC98\Bin
set ALT_DXSDK_PATH=C:\dev\dxsdk
REM set ALT_CACERTS_FILE=C:\jdk_build_tools\cacerts
REM set ALT_MSVCRT_DLL_PATH=C:\Windows\System32
set ALT_MSVCR71_DLL_PATH=C:\Windows\System32
set ALT_MSVCP71_DLL_PATH=C:\Windows\System32
set ALT_UNICOWS_DLL_PATH=c:\dev\mslu
REM set ALT_UNICOWS_LIB_PATH=c:\dev\mslu
set ALT_UNICOWS_LIB_PATH=c:\dev\psdk\Lib
set MILESTONE=beta
set SECURITY_BASELINE_142=1.4.2_10
set SECURITY_BASELINE_150=1.5.0_06

echo %PATH%

REM make all DEV_ONLY=true
REM make j2se_only DEV_ONLY=true
make scsl DEV_ONLY=true

Message was edited by: atripp

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-06-16

I may be able to help with some of those DT_RETURN_MARK and FP_SELECT macros...

First off, unless you're building on Solaris 10 or better, all of those macros should end up empty, so you shouldn't be breaking anything by just commenting them out in that file.

Second, even after looking at your analysis, I don't see which macro is not getting enough arguments. FP_SELECT(X,Y,Z) expands into FP_SELECT_X(Y,Z), right?

The point of DT_RETURN_MARK_FOR is to convert integer types into something like this (again, only on Solaris 10):

DT_RETURN_MARK_FOR(Boolean, func, bool, value) -->
DTraceReturnProbeMark_func dtrace_return_mark(value);

... while floating point ones turn into this:

DT_RETURN_MARK_FOR(Float, func, bool, value) --->
DTraceReturnProbeMark_func dtrace_return_mark;

(unfortunately, it's tough to do it in a more straightfoward way because of the fact that this macros are needed within other macros where the "Boolean"/"Float", etc. are macro parameters themselves).

Joined: 2003-07-15

>I may be able to help with some of those DT_RETURN_MARK and >FP_SELECT macros...

>First off, unless you're building on Solaris 10 or better, >all of those macros should end up empty, so you shouldn't >be breaking anything by just commenting them out in that file.

Yea, I spent hours trying to decipher that nest of macros. What a mess :( IIRC I ended up just commenting it all out as you suggest.

This is the sort of thing that should really be cleaned up, IMO. Should be a big "#ifdef SOLARIS" or something. I know #ifdefs are ugly, but it's far better than a someone who's compiling on Windows pulling his hair out to get code to compile that he doesn't even need.

And another, dumber question: what is this feature, and why is it on Solaris only? More generally, is there any sort of "Guide to the JDK source code?"

Joined: 2004-09-03

Just FYI... Many of these compilation errors should be fixed in B88.


Joined: 2003-06-10

Why isn't there a MSVC++ project/solution file for all the native bits that can simply be 'built' with one click? Reading through this thread I feel like I've gone back in time and ended up in the 70's.

Joined: 2004-09-03

Sorry about the 70's flashback, I understand this is frustrating.

I'm not sure how many of our engineers do development directly on Windows anymore, and specific teams may have MSVC projects to build just their part of the JDK, I'm not sure. Also, many engineering teams have automated builds or build submittal services such that they rarely need to build on all the platforms. Some teams do nothing but Java development.

I know the hotspot team has a MSVC project file for building hotspot which fits well since it's a big C++ project, I don't know of anything for the rest of the JDK. Building JDK/JNI libraries involves javac compilations, javah runs to get the header files, and then native C/C++ compilations. I'm not sure that a C/C++ IDE really supports this kind of mixed Java/C/C++ building. And even if it did, it would be for one platform, not a good overall solution.

I've been planning on trying the new C/C++ module for NetBeans 5 (see, which supposedly would work on all platforms. But I haven't had the time to try this yet. If anyone wanted to try this I'd be interested in their experiences.


Joined: 2003-06-10

I understand the issue with javac + javah. There are many solutions though.

The most basic that I can think of is to have an Ant build file for the Java bits of the entire JDK. It could dispatch bits of work to build files of various sub sections of the JDK, e.g. Swing could have a separate build file, as well as many of the other frameworks within the JDK. The point being, anyone with some version of Java 6 pre-installed should be able to build all of the Java bits simply by invoking one Ant command at the root of the build tree. There should be absolutely no set-up required other than installing a Java 6 JDK and Ant and setting JAVA_HOME.

If you have a NetBeans project that builds all of the Java parts of the JRE (which obviously you should - I haven't checked yet, I got scared reading through all the headaches that people had compiling on Windows), then many of these Ant build files will already be available.

When it comes to the native bits the Ant file can easily invoke different compilers based on system properties. To force a particular compiler you could just define a property. Then Ant would simply run the native project for MSVC by invoking "msdev.exe" with the project file appropriate for the JNI libraries being built. A smart build script could simply check the default install locations for MSVC++ if the appropriate env-var or property was not set. For unix systems that typically use GCC it would invoke the appropriate MAKE file, etc.

There is really no reason that the build process shouldn't be a simple one step procedure for most systems. Maybe two or three steps if you need to set a couple environment variables or properties to direct the script to the correct directories. Someone would have to put in the time to make it work that way of course.

Sun only supports three platforms, Solaris, Linux, and Windows. Of the three I assume Windows is still what the majority of the developers will be using. A painless build experience on Windows would go a long way in terms of boosting community support from Windows users. If Sun put in that initial effort to get a smooth painless Windows build going, I'm sure it will pay off.

On Windows almost *everyone* uses the same compiler (Microsoft's), though perhaps differnt versions of it. There a people that use the intel compiler to squeeze a bit of performance out of it when they need to, but *nobody* uses GCC (or any variant of it) on Windows.. well except people that want to experience that sort of pain. GCC wants to run on unix and every attempt at running it on Windows that I've seen is just horrible from a Windows-user's perspective. Yet last I heard the C/C++ module for NetBeans was going to target GCC on Windows instead of what everyone actually uses. I've pointed this out when they asked for feedback, but I'm not going to hold my breath waiting for them to properly support the Windows platform.

Joined: 2004-09-03

I think you have greatly simplified what it would take to create Ant scripts. You really need to live in the JDK build process to understand the complex dependencies we have (some necessary, and some unnecessary I agree). I have no doubt that what you suggest is ultimately possible, just at what cost and what end result benefit. Would Ant build scripts, after adding in all the dependencies and build order issues, be any more readable or cleaner or faster than the Makefiles? Maybe, maybe not, but it would be a long difficult task to find out, and possible a risky venture if you mis-spelled a few C++ compiler options. :^(

And also by the way Sun builds 8 variations: Windows 2000 X86, Windows 2003 X64/AMD64, Linux X86, Linux X64/AMD64, Solaris X86, Solaris X64/AMD64, Solaris SPARC, and Solaris SPARCV9 (the 4 Solaris builds could be considered 2, but we really build them separately). Each is different and we deal with multiple compilers: 2 versions of gcc, 2 versions of MSVC C++, and one version of Sun Studio 11. Potentially 5 different spellings of compiler flags but usually just 3. :^(

But at a high level, I agree completely that we need a one button approach to building the JDK, no debate there. What happens under that button shouldn't matter that much, as long as it happens as fast as possible. If that turns out to be an Ant script, fine by me, but so far we only have Ant scripts to build various pieces of the JDK, and only at certain phases of the JDK build. That's a far cry from one that does everything. I'm hoping that the NetBeans C/C++ module might help in this regard. If firing up NetBeans on the JDK and clicking on the "Build" button worked, wouldn't that fit the bill? ;^)

I understand your view on Windows compilers, and to some degree share your opinions, but I'm basically a Unix developer at heart. When it comes to Windows and the build issues on Windows, I find the platform pretty hard to deal with.


Joined: 2003-07-15

> Would Ant build scripts, after adding in all the dependencies and build order issues, be any more readable or cleaner or faster than the Makefiles?

I would think it must surely be more readable and cleaner. If for no other reason than avoiding make syntax and having just a single builder - ant, as opposed to gnumake, MS make, Solaris make.

As for speed, who knows. I doubt there'd be a big difference.

> I have no doubt that what you suggest is ultimately possible, just at what cost and what end result benefit.

From my perspective, I'd bet that the complexity of building the JDK is far more of a hinderance than the fact that the JDK is not-true-open-source. Even if you do open-source the JDK and then get a flood of people outside Sun trying to compile it, many are going to hit these same
problems. Not too many people are willing to spend a few days getting something to compile these days.

As for swpalmer's observation that few people using gcc on windows, and the few who do experiencing trauma, that's interesting to hear...I didn't realize that. Now I wish I had title this thread "one-button JDK build needed" rather than the reference to gcc :)

Joined: 2005-06-21

We are working on getting the idealKit.hpp, escape.cpp and constMethodOop.hpp issues resolved.

As for the macro problem, it isn't clear what is causing the issue, but we are open to suggestions.

Joined: 2003-07-15

Since I'm trying to use MSVC++ 2005 Express Edition, rather than the standard MSVC++ 6.0 professional edition, here are a few links at the Microsoft site that may explain some of the differences:

New Compiler Features for VC++ 2005:

Summary of Compile-Time Breaking Changes for VC++ 2003:

New [presumably 2005?] Compiler Features:

Looks like this one:
...may explain the problem I was getting about "not enough arguments supplied to a macro" earlier.

Joined: 2003-08-29

I'm using version 14.00.50727.42 of the Microsoft C++ compiler.

Joined: 2003-07-15

I was getting that compile error that I mentioned earlier about variables being initialized at their declaration for these lines in share/vm/oops/constMethodOop.hpp:
static u2 MAX_IDNUM = 0xFFFF;
static u2 UNSET_IDNUM = 0xFFFF;

I wasn't able to move them to constMethodOop.cpp - couldn't find the appropriate constructor, and when I added my own constructor (for class constMethodOopDesc), the compiler complained that the code was duplicate - the constructor already existed, but I can't find it. Sorry, my C++ is a little rusty.

So I did a hack: replacing references to those two variables with just "0xFFFF" and now hotspot compiles successfully.

Joined: 2003-07-15

Got this error:

3 [main] sh 2564 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION

...turns out I just had a source file open in an editor at the time.

Joined: 2003-07-15

Got this error:

c:\dev\mustang\hotspot\src\os\win32\vm\os_win32.cpp(1303) : error C2065: 'IMAGE_FILE_MACHINE_AMD64' : undeclared identifier

looks like that symbol is missing from

I'm just going to comment the offending line for now. Doesn't look like it should break anything (famous last words!)

Joined: 2003-07-15

Got these errors:
c:\dev\mustang\hotspot\src\share\vm\opto\escape.cpp(314) : error C2374: 'ni' : r
edefinition; multiple initialization
c:\dev\mustang\hotspot\src\share\vm\opto\escape.cpp(305) : see declaration of 'ni'
c:\dev\mustang\hotspot\src\share\vm\opto\escape.cpp(315) : error C2228: left of
'.escape_state' must have class/struct/union type
c:\dev\mustang\hotspot\src\share\vm\opto\escape.cpp(333) : error C2374: 'ni' : r
edefinition; multiple initialization
c:\dev\mustang\hotspot\src\share\vm\opto\escape.cpp(305) : see declaration of 'ni'

'.escape_state' must have class/struct/union type
c:\dev\mustang\hotspot\src\share\vm\opto\escape.cpp(378) : error C2374: 'i' : redefinition; multiple initialization
c:\dev\mustang\hotspot\src\share\vm\opto\escape.cpp(369) : see declaration of 'i'

Looks like a compiler bug where a declaration like this:
for (int i=0; i<10; i++) {
...has the scope of "i" extend beyond the end of the "for", causing these variable shadowing errors. Fixed by renaming variables.

Joined: 2003-07-15

Another case of a variable initialized in a header:
c:\dev\mustang\hotspot\src\share\vm\opto\idealKit.hpp(97) : error C2258: illegal
pure syntax, must be '= 0'
c:\dev\mustang\hotspot\src\share\vm\opto\idealKit.hpp(97) : error C2252: 'first_
var' : pure specifier can only be specified for functions
c:\dev\mustang\hotspot\src\share\vm\opto\idealKit.cpp(150) : error C2065: 'first
_var' : undeclared identifier
c:\dev\mustang\hotspot\src\share\vm\opto\idealKit.hpp(97) : error C2258: illegal
pure syntax, must be '= 0'
c:\dev\mustang\hotspot\src\share\vm\opto\idealKit.hpp(97) : error C2252: 'first_
var' : pure specifier can only be specified for functions

...moved initialization into the constructor.

Joined: 2003-07-15

Next, we get a bunch of warnings:
c:\dev\mustang\hotspot\src\share\vm\prims\jni.cpp(1306) : error C2220: warning treated as error - no object file generated
c:\dev\mustang\hotspot\src\share\vm\prims\jni.cpp(1306) : warning C4003: not enough actual parameters for macro 'FP_SELECT_Boolean'
c:\dev\mustang\hotspot\src\share\vm\prims\jni.cpp(1306) : warning C4003: not enough actual parameters for macro 'FP_SELECT_Boolean'
...and lots more of the same...

After a couple of nasty hours of tracking down macros calling other macros...

These macros all take 2 args:
#define FP_SELECT_Boolean(intcode, fpcode) intcode
#define FP_SELECT_Byte(intcode, fpcode) intcode
#define FP_SELECT_Char(intcode, fpcode) intcode
#define FP_SELECT_Short(intcode, fpcode) intcode
#define FP_SELECT_Object(intcode, fpcode) intcode
#define FP_SELECT_Int(intcode, fpcode) intcode
#define FP_SELECT_Long(intcode, fpcode) intcode
#define FP_SELECT_Float(intcode, fpcode) fpcode
#define FP_SELECT_Double(intcode, fpcode) fpcode

And DEFINE_CALLMETHOD macro refers to DT_RETURN_MARK_DECL_FOR, which refers to DT_RETURN_MARK_FOR, which calls FP_SELECT:

#define DT_RETURN_MARK_FOR(TypeName, name, type, ref) \
FP_SELECT(TypeName, \
DT_RETURN_MARK(name, type, ref), DT_VOID_RETURN_MARK(name) )

which looks like:
#define FP_SELECT(TypeName, intcode, fpcode) \
FP_SELECT_##TypeName(intcode, fpcode)

replacing DT_RETURN_MARK_FOR with this:
#define DT_RETURN_MARK_FOR(TypeName, name, type, ref) \
FP_SELECT(TypeName, 1, 1)
...causes the compile error to disappear.

So here are the culprits:
#define DT_RETURN_MARK(name, type, ref) \
DTRACE_ONLY( DTraceReturnProbeMark_##name dtrace_return_mark(ref) )
#define DT_VOID_RETURN_MARK(name) \
DTRACE_ONLY( DTraceReturnProbeMark_##name dtrace_return_mark )

And DTRACE_ONLY is set elsewhere like this:
#if defined(SOLARIS) && defined(DTRACE_ENABLED)
#define DTRACE_ONLY(x) x
#else // ndef SOLARIS || ndef DTRACE_ENABLED
#define DTRACE_ONLY(x) I can't see how this compiles except on SOLARIS with DTRACE_ENABLED set. Or, more likely, the "standard" compiler doesn't complain when macros don't get enough args passed to them.

The only hack I could come up with to get past all this confusion was to add:
#define FP_SELECT1(code) code
and then change each instance of

I just don't understand enough of what's going on to make a correct fix. I have no idea whether I broke something.

Any help?

Joined: 2003-12-31

There's definitely something weird going on. It's as if the build thinks you're building on Solaris and not windows.

What's your OS? Could you post the "Platform Settings" section from the build log.

On our nightly build it looks like this:
Build Platform Settings:
USER = java_re
PLATFORM = windows
ARCH = i586
LIBARCH = i386
PROCESSOR_IDENTIFIER = x86 Family 15 Model 2 Stepping 7, GenuineIntel
WINDOWS_VERSION = 5 0 Service Pack 3
MKS_VER = 6.1 [requires at least 6.1]
OS_VERSION = 5 [requires at least 5]
OS_NAME = nt
TEMP_FREE_SPACE = 31833520
FREE_SPACE = 31833520

Or just type "gnumake sanity" and post the output..


Joined: 2003-07-15

below is the output from "gnumake sanity".
I realize that my version of the compiler and linker is wrong - see original post.

Build Machine Information:
build machine = JAZILLIAN1

Build Directory Structure:
CWD = /cygdrive/c/dev/mustang/control/make
TOPDIR = ../..
CONTROL_TOPDIR = ../../control
HOTSPOT_TOPDIR = ../../hotspot
J2SE_TOPDIR = ../../j2se
MOTIF_TOPDIR = ../../motif
DEPLOY_TOPDIR = ../../deploy
INSTALL_TOPDIR = ../../install

External File/Binary Locations:
PREVIOUS_JRE_BUNDLE = J:/re/j2se/1.5.0/archive/fcs/bundles/windows-i586/jdk-1
PREVIOUS_JDK_BUNDLE = J:/re/j2se/1.5.0/archive/fcs/bundles/windows-i586/jdk-1

Build Directives:
BUILD_J2SE = true

Hotspot Settings:
HOTSPOT_OUTPUTDIR = C:/dev/mustang/output/hotspot/outputdir
HOTSPOT_EXPORT_PATH = C:/dev/mustang/output/hotspot/import

Bootstrap Settings:
BOOTDIR = c:\dev\jdk1.5
ALT_BOOTDIR = c:\dev\jdk1.5
BOOT_VER = 1.5 [requires at least 1.5]
OUTPUTDIR = C:/dev/mustang/output
ALT_OUTPUTDIR = C:/dev/mustang/output
ABS_OUTPUTDIR = C:/dev/mustang/output

Build Tool Settings:
JDK_DEVTOOLS_DIR = J:/devtools

Patch Build Settings:
RTPATCH_DIR = c:/Progra~1/pocketsoft/rtpatch

NEW_IMAGE_JRE_DIR = C:/dev/mustang/output/j2re-image
NEW_IMAGE_SDK_DIR = C:/dev/mustang/output/j2sdk-image
BUNDLE_DATE = 25_may_2006

BASE_IMAGE_JRE_DIR = C:/dev/mustang/output/j2re-image
BASE_IMAGE_SDK_DIR = C:/dev/mustang/output/j2sdk-image

Install Build Settings:
ISHIELDDIR = C:/Program Files/InstallShield/Developer
BUILDER = C:/Program Files/InstallShield/Developer/System/ISCmdBld.exe
WARNING: You appear to be using an unsupported version of Windows Professional 2
The supported version is Windows Professional 2000 5 0 Service Pack 4.

You appear to be using 5 1 Service Pack 2

does not exist, check your value of ALT_HOTSPOT_DOCS_IMPORT_PATH.

WARNING: To build Java 2 SDK 1.6.0 you need :
VS2005 - link.exe version "7.10.3077"
Specifically the Visual Studio .NET 2005 link.exe.
You appear to be using Linker version "8.00.50727.42"
Please install the required version of Visual C++ and start your build ag

WARNING: The windows compiler must be version VS2005 13.10.3077
Specifically the Visual Studio .NET 2005 Optimizing compiler.
You appear to be using compiler version: 14.00.50727.42
The compiler was obtained from the following location:
Please change your compiler.

ERROR: You do not have access to the previous java release jre bundles.
Please check your access to
and/or check your value of ALT_PREVIOUS_RELEASE_PATH or ALT_PREVIOUS_JRE_
This will affect you if you build the images target.

ERROR: You do not have access to the previous java release sdk bundles.
Please check your access to

and/or check your value of ALT_PREVIOUS_RELEASE_PATH or ALT_PREVIOUS_JDK_
This will affect you if you build the images target.

Exiting because of the above error(s).

Joined: 2004-09-03

Try using 'gnumake dev-sanity' instead of 'gnumake sanity',
and 'gnumake dev' for a build. It will short circuit some of these checks that don't make sense for you.


Joined: 2003-07-15

c:\dev\mustang\hotspot\src\share\vm\oops\constMethodOop.hpp(249) : error C2258:
illegal pure syntax, must be '= 0'
c:\dev\mustang\hotspot\src\share\vm\oops\constMethodOop.hpp(249) : error C2252:
'MAX_IDNUM' : pure specifier can only be specified for functions
c:\dev\mustang\hotspot\src\share\vm\oops\constMethodOop.hpp(250) : error C2258:
illegal pure syntax, must be '= 0'

I fixed it by just declaring the variables in the header and moving the initialization into the .cpp file.