How to test a fresh HotSpot build on Windows without building the whole JDK?

[Volker Simonis]

Hi Tim,

thank you very much for the hints and insights. I'll try the manifest
stuff tomorrow. Regarding your suggestion to use the gamma launcher, -
I'd like to, this was my initial intention - however there's no gamma
launcher for windows (i.e. 'hotspot/src/os/windows/' contains no
'launcher/' subdirectory with the relavant files like the
corresponding 'linux/' and 'solaris/' subdirectories). Did you mean I
should build something equivalent to the Unix gamma launcher for
Windows by using the corresponding files from the jdk workspace?
Would this be worthwhile if you say that it is not very good to mix
different runtimes in the same address space? Aren't the other native
libraries of the binary JDK  7 build dependant on "msvcr71.dll" as
well?

Thank you and best regards,
Volker

PS: I also had to set "/D _CRT_NONSTDC_NO_DEPRECATE" (see
http://msdn.microsoft.com/en-us/library/ms235384(VS.80).aspx) to make
some deprecated functions visible without a leading "_". Morover I had
to insert some cast to avoid warnigs like "result of 32-bit operation
converted to 64-bit...). Didn't you had these problems when you did
your VS 2008 build? I couldn't find any related changes but if you
want, I can post the diffs.


On 11/19/08, Tim Bell <Tim.Bell at sun.com> wrote:
> Volker Simonis wrote:
>
> > Here are my findings so far:
> >
>  [... snip! ...]
>
>
> > So apparently I have to link jvm.dll somhow specially if I use VS2005
> > and use "mt.exe" in order to add a mainfest to it. Does anybody has
> > experience with this?
> >
>
>  The VS2005 and VS2008 runtime libraries (msvcr80.dll or msvcr90.dll
> respectively) will refuse to run if they do not find the correct 'manifest'
> information when loaded.
>
>  Starting with VS2005, every use of the ld command to create a .dll or a
> .exe will also create a .manifest file in the same directory.  That manifest
> is what the runtime library is checking.
>
>  If you move or copy a .exe or a .dll, your choices are:
>
>  1) Also put the .manifest file there so the runtime can find it.
>
>  2) Use the mt command to insert the manifest as an attribute on the .dll or
> .exe file just created (the 'ld' command itself will not do that).  Once you
> add the manifest as an attribute, you don't need to keep track of the extra
> .manifest file.
>
>  The changes in 6764892 [Note 1] implement option 2.  This is what all the
> work under 6523947 will do.
>
>
> > Thank you and best regards,
> > Volker
> >
> > PS: I just rememered the change "6764892: VS2008 changes required to
> > compile hotspot sources" which has been recently posted on the list:
> >
> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c07cda72b7d.
> > But it was in hotspot-comp and I synced jdk7:(  I'll try it tomorrow -
> > looks like this could solve my problems...
> >
>
>  You want these changes.  They are headed for the JDK7 HotSpot master, but
> have not been pushed up yet.  I just marked 6764892 as public, so it should
> be pushed in the bug parade in the next few days.  The relevant information
> is in the changeset referenced in [Note 1].
>
>  Since you are building your JVM using VS2005, you will get msvcr80.dll with
> it.  Inserting that jvm.dll into a pre-built JDK 7 will be problematic
> because the current JDK 7 builds use Visual Studio 2003 and hence
> msvcr71.dll with all other native libraries.  In our experience, nothing
> good will happen if you try mixing two runtimes in the same process address
> space.  As a result of this incompatibility, I have been doing full control
> builds of the entire JDK while working on the fixes for 6523947 and related
> bug-IDs 6728735, 6733976, 6764892, 6759959, 6754862 [Note 2].
>
>  If you can build the gamma launcher using VS2005 and run that to quickly
> test your JVM you will probably be better off.
>
>  Hope this helps -
>
>  Tim Bell
>
>  [Note 1]
>
> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3c07cda72b7d
>
>  [Note 2]
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6523947
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728735
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6733976
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6764892
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6759959
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6754862
>
>