Skip to main content

Build b41 & Microsoft Visual Studio.NET 2003 Professional Edition compiler

10 replies [Last post]
vijayj
Offline
Joined: 2004-10-26
Points: 0

Hi Folks,

We have promoted build b41 today. Windows-i586 bundles were compiled with Microsoft Visual Studio.NET 2003 Professional Edition compiler (VS.NET 2003). So we have officially rolled over to VS.NET 2003 for our nightly windows-i586 build. Going forward we will be using VS.NET 2003 for our nightly build.

http://www.java.net/download/jdk6/binaries/

How to build mustang source using VS.NET 2003?.

The Microsoft Visual Studio.NET 2003 Professional Edition compiler can also be used for building the JDK 6.0. The compiler and other tools are expected to reside in the location defined by the variable VS71COMNTOOLS, which is set by the Microsoft Visual Studio.NET installer.

It is highly recommended that you run VCVARS32.BAT (usually found in C:\"Program Files"\"Microsoft Visual Studio .NET 2003"\Vc7\bin\VCVARS32.BAT) to set MSVCDIR, INCLUDE, LIB, and the PATH prior to building the JDK.

If your compiler resides in a place other than the default, you can set ALT_COMPILER_PATH to point to the location of the cl.exe compiler binary. If you are using MS VS.NET 2003 then you don't need to set ALT_MSDEVTOOLS_PATH variable. The compiler and tools binaries must be in the PATH.

http://www.java.net/download/jdk6/build-windows-i586.html#msvc

We are also using the Platform SDK in Microsoft Visual Studio.NET 2003 for building the Java Plug-in and/or Java Web Start. This MSSDK is usually found in C:\"Program Files"\"Microsoft Visual Studio .NET 2003"\Vc7\PlatformSDK. If you are using VS.NET 2003 compiler for your build then you don't have to set ALT_DEPLOY_MSSDK.

http://www.java.net/download/jdk6/build-windows-i586.html#mssdk

Please let me know if you run into any issues.

Thanks,
Vijayan.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kendallb
Offline
Joined: 2005-07-15
Points: 0

Hi Guys,

I am really new to Java but this thread caught my eye. Since you are building an Open Source JDK platform, have you considering looking into supporting the Open Watcom compiler and tools?

The Open Watcom compiler does a great job building x86 code, has one of the best debuggers around and comes with a pretty complete Open Source Win32 SDK out of the box. We actually share the Win32 SDK code with the GNU based Mingw32 project, and I imagine it probably has everything you need to build Mustang.

Better yet the Open Watcom compilers come with full source code under the Sybase Public License, supports 32-bit DOS, OS/2 and Win32 development out of the box and we have preliminary versions for Linux (you have to build from source to get the Linux versions though). And it has it's own complete C/C++ runtime library, so you don't need to worry about the Microsoft C runtime library DLL's :-)

Considering this is an Open Source JDK, it might be a worthwhile project to get it building with Open Watcom on the platforms that Open Watcom supports. The Open Watcom developer community is very active, so if there are issues with the compiler that prevent it from compiling the JDK, the developer community would be very interested in fixing the compiler.

I am too busy to look into this at the moment, but in a few weeks I might be able ot help work on getting the JDK building with Open Watcom.

http://www.openwatcom.org

kellyohair
Offline
Joined: 2004-09-03
Points: 0

Hopefully we aren't doing anything to block the use of the Open Watcom compiler and tools, and if we are, please let me know and I will try and deal with it. I would love to see the JDK successfully built with these compilers, and if indeed someone managed to do this, we would very likely accept the source change contributions and perhaps provide some testing resources if we were given the resulting Watcom built binaries.

robinliu
Offline
Joined: 2004-07-11
Points: 0

when I tried to compile using VS.Net 2003, I got the following error.

----------------------------------------------------------
ERROR: The Microsoft Layer for Unicode static library (unicows.lib),
which is located at:
D:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/PlatformSDK/Li
b//unicows.lib
is not the one that is included in the November 2002 edition of
the Microsoft Platform SDK (Build 5.2.3718.1).
Please install the required version of unicows.lib
----------------------------------------------------------

just wondering if anyone happens to have the required UnicoWS.lib. If so, could you please give a link or send it to me by email: liuchunjian@hotmail.com

thanks!

vijayj
Offline
Joined: 2004-10-26
Points: 0

We are working on simplifying this but in the meantime you can take a look at the below URL.

http://forums.java.net/jive/thread.jspa?threadID=627&messageID=15161

Thanks,
Vijayan.

robinliu
Offline
Joined: 2004-07-11
Points: 0

Thank you very much, it is very very helpful.

Cheers,
Robin

sbogrett
Offline
Joined: 2004-12-01
Points: 0

What are your thoughts on using the latest Intel compiler, which is a much better optimizing compiler, rather than Visual Studio?

Regards,
Steven Bogrett

kellyohair
Offline
Joined: 2004-09-03
Points: 0

I don't know that much about the Intel compilers, but building with any other set of compilers would be a fine exercise, just not one on my priority list right now. The Windows code does use the windows specific #include files, like , and I have no idea what that would mean when using a non-Microsoft compiler.

Performance is important, but correctness of the code is critical unless you want to spend days or maybe weeks tracking down compiler optimization bugs or issues. So just because a compiler wins performance benchmark wars may not make it a good choice for building something like the JDK. A long time ago the Intel compiler was a benchmark warrior, but maybe it's more of a quality product compiler now? I honestly don't know.

Certainly any effort like this probably ought to start with no optimizations just to get past any compiler option or build issues unrelated to optimization issues, as a kind of phase one. Then bump up the opt level in phase two.

In general, not many of the native shared libraries in the JDK supposedly impact Java performance. Certainly the VM (libjvm.so/jvm.dll), AWT (libawt.so/awt.dll), the image processing libraries, and maybe things like hprof should be highly optimized, but it's not clear what the benefit of higher native code optimization is in many cases. I've been trying to boost the default optimization level up but it's a bit of a speed vs. size issue at some point, so it is currently at a -O2 level now on Solaris/Linux. I've been told that we could bump up the default opt level with the VC7 compilers but haven't done that one yet.

-kto

rogerhernandez
Offline
Joined: 2005-02-23
Points: 0

Actually, the Intel compiler is a plug-in into Visual Studio. It uses the existing header files and libraries, so it should be fully compatible with the existing make files.

kellyohair
Offline
Joined: 2004-09-03
Points: 0

Interesting, I did not know that.

Then indeed, it might be worth trying. The only issue then is watching out for compiler errors, and maybe getting the compiler command line right if the options differ.

kellyohair
Offline
Joined: 2004-09-03
Points: 0

To add to Vijay's information and as a clarification on mixing DLL's built with different compilers, be very careful. The JDK is built with the option /MD so that the runtime library is dynamically linked in and when we were using the older VC6 compiler it was using msvcrt.dll. Now with the Visual Studio .NET 2003 (VC7.1) compiler we will be using the msvc*71.dll libraries. In some situations you can mix DLL's but we don't guarantee it, the different runtimes don't seem to co-exist together very well.

For example, if you are building hotspot with VC6, and place JVM.DLL inside a JDK built with VC7.1, you will also need to find a copy of HPI.DLL that was built with VC6. That's because the JVM and HPI pass around FILE* and socket handles, and they are not compatible between these runtimes.

Building a JVM.DLL with VC7.1 and trying to place it inside a VC6 built JDK just will not work. So in general we don't recommend missing DLL's built with VC6 and VC7.

Also, for you CYGWIN users out there, apparently there are situations where these runtime DLL's are given execute permission when copied into the java.exe directory. This causes the java.exe to fairly silently just die or fail. So make sure these msvc*71.dll files have execute permission.