OpenJDK Windows build with Visual Studio 2010 Express Edition
Phil Race
philip.race at oracle.com
Wed Jun 16 17:06:13 UTC 2010
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
>
More information about the build-dev
mailing list