As a follow up to this ..
I've pushed a couple of fixes which are so far only in the build forsest
1) freetypecheck now builds with VS2010 and thus OpenJDK builds with
Visual Studio (Express or Professional)
2) I downloaded the free Windows 7.1 SDK which has the 64 bit compiler
from VS2010 (Express
only has 32 bit), and made the small tweak necessary to adjust for its
path.
Result: I was able to build 64 bit windows with the new compilers.
Tested operating systems were:
32 bit on XP SP3
64 bit on Windows 2003_R2
I doubt Windows Vista or Windows 7 will introduce any compiler specific
issues
but I would not be surprised to learn that there are cygwin issues.
Also problems seem to vary depending on cygwin version.
So in summary at this time (with the build repo forest), you can
1) Use Visual Studio 2010 Professional (the paid version) to build ALL
JDK7 (including
non-open code), either 32 or 64 bit
2) Use Visual Studio 2010 Express (the free, as in no cost, version) to
build 32 bit
versions of all open repos (and all the non-deploy closed ones too ...)
3) Use the standalone Windows SDK 7.1 (free as in no $$ involved) and its
included 64 bit compilers to build all the open repos for 64 bit.
There are other possibilities, such as using the 7.1 SDK to build 32 bit
as well.
I didn't try that and I suspect that may need another path tweak.
Finally, saying this is possible, doesn't mean that you don't have to set up
your environment. You need cygwin, ant, tools such as zip, unzip, gnumake
and the DirectX SDK .. none of these requirements change because of VS2010
so I will not go into these here.
One thing I note that probably could use some automatic detection is
that I think you will now have to explicitly set ALT_MSDEVTOOLS_PATH for
these
VS2010 based builds, whereas with VS2003 it may not have been necessary.
Basically you need to set this to point at the SDK's bin directory.
-phil.
On 6/13/2010 12:41 AM, Phil Race wrote:
At this time we've not tried openjdk builds with VS2010
I know freetype check has issues but not hard ones. It appears that's
the only issue, but fixing it is TBD.
Your various path issues are likely not unique to VS2010
The failure to find "rc" and "mt" is probably most easily rectified by
set ALT_MSDEVTOOLS_PATH
but if that's so, automatically detecting a reasonable value for that is
surely better than your hardwired paths. Also TBD.
-phil.
Damjan Jovanovic wrote:
Hi
Once again
(http://mail.openjdk.java.net/pipermail/build-dev/2009-December/002641.html)
I am compiling OpenJDK on Windows Vista with Visual Studio 2010
Express Edition.
OpenJDK version: recent OpenJDK7 AWT repository HEAD, 5bbc7438b333 tip
Windows: Vista 32 bit
Visual studio: 2010 Express Edition
Cygwin: 1.5.25-15
Bootstrap JDK: JDK 6u20
Binary plugs: jdk-7-ea-plug-b97-windows-i586-10_jun_2010
DirectX SDK: summer 2004
Ant: 1.8.1
Freetype: 2.3.4, from the binary Windows installer
make: 3.81 from cmake.org
>From last time, I knew to do "set > a.txt", "/path/to/vcvars32.bat",
"set > b.txt", "diff -u a.txt, b.txt" in Cygwin, then convert and
populate the changed environment variables to get the Visual Studio
compilers working.
1. Compilation died very early as freetypecheck fails to compile due
to missing crtassem.h; much messing around with freetypecheck.c and
commenting stuff out kept on failing to compile or link so I wrote the
following:
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Required version of freetype: 2.3.4\n");
printf("Detected freetype headers: 2.3.4\n");
printf("Detected freetype library: 2.3.4\n");
return 0;
}
Compiled that with mingw, and copied the .exe where it's expected, to
fool the build env into proceeding.
2. Complation then failed because there's "nothing to do"; apparently
the wrong "find" command was in my $PATH first.
3. The new $PATH messed up the path to "make", fixed it again.
4. Next there's an exception because jaxp needs Internet access... set
that up and tried again.
5. It's hotspot's turn to fail next:
link.exe /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib comd
lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib
Wsock32.lib w
inmm.lib /nologo /machine:I386 /opt:REF /opt:ICF,8 /map /debug
/subsystem:conso
le /out:adlc.exe main.obj adlparse.obj archDesc.obj arena.obj dfa.obj
dict2.obj
filebuff.obj forms.obj formsopt.obj formssel.obj opcodes.obj
output_c.obj output
_h.obj
/usr/bin/link: extra operand `user32.lib'
Try `/usr/bin/link --help' for more information.
NMAKE : fatal error U1077: 'C:\cygwin\bin\link.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio
10.0\VC\BI
N\nmake.EXE"' : return code '0x2'
Stop.
make[3]: *** [generic_build2] Error 2
Apparently /usr/bin/link is the wrong "link"...
$ which -a link
/usr/bin/link
/bin/link
/cygdrive/c/Program Files/Microsoft Visual Studio 10.0/VC/BIN/link
/usr/bin/link
/bin/link
So in $PATH I first needed VC's paths with "link", then the path to
cmake.org's "make", then Cygwin's paths with "find", then everything
else.
6. Next a wrong path to "rc". I reapplied one of my old patches:
diff -r ca34cfff70a4 make/common/shared/Compiler-msvc.gmk
--- a/make/common/shared/Compiler-msvc.gmk Fri Nov 27 16:07:32
2009 +0300
+++ b/make/common/shared/Compiler-msvc.gmk Thu Dec 10 19:13:15
2009 +0200
@@ -34,8 +34,8 @@
CCC = $(COMPILER_PATH)cl
LIBEXE = $(COMPILER_PATH)lib
LINK = $(COMPILER_PATH)link
- RC = $(MSDEVTOOLS_PATH)rc
- RSC = $(MSDEVTOOLS_PATH)rc
+ RC = "C:/Program Files/Microsoft SDKs/Windows/v7.0A/Bin/rc"
+ RSC = $(RC)
LINK32 = $(LINK)
# Fill in unknown values
@@ -78,7 +78,7 @@
#rebase and midl moved out of Visual Studio into the SDK:
REBASE = $(MSDEVTOOLS_PATH)/rebase
MTL = $(MSDEVTOOLS_PATH)/midl.exe
- MT = $(MSDEVTOOLS_PATH)mt
+ MT = "C:/Program Files/Microsoft
SDKs/Windows/v7.0A/Bin/mt"
ifndef COMPILER_PATH
COMPILER_PATH := $(error COMPILER_PATH cannot be empty here)
endif
7. I had to reapply the above MT fix to the Visual Studio 10 section
of that file as well.
It then successfully compiled. I am attaching the environment
variables I used.
All in all, still some work, but much easier than my last attempt.
Thank you
Damjan Jovanovic
