something wrong with hotspot builds in build-infra

[Kelly O'Hair]

On Oct 17, 2012, at 8:57 PM, David Holmes wrote:

> The log
> 
> http://prt-web.us.oracle.com//archive/2012/10/2012-10-17-145309.kohair.jdk8-build//logs/windows_i586_5.1-fastdebug.log
> 
> doesn't indicate configure is using fixpath at all.
> 
> Tools summary:
> * Boot JDK:       /cygdrive/c/jprt/products/p1/jdk7u7~1/jdk17~1.0_0
> * C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~1/micros~2.0/vc/bin/cl)
> * C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~1/micros~2.0/vc/bin/cl)
> 
> 
> I am not familiar with the windows build, but could this be the problem with the explicit setting of MAKE?

I doubt it, but I can't say for sure.

-kto

> 
> David
> 
> On 18/10/2012 5:33 AM, Magnus Ihse Bursie wrote:
>> On 2012-10-17 18:11, Kelly O'Hair wrote:
>>> Something called fixpath.exe is failing when doing the adlc.make nmake
>>> makefile in hotspot.
>>> 
>>> 
>> "fixpath" is the new name of "uncygdrive", since it now supports msys as
>> well as cygwin. It will take a path such as /cygdrive/c/mydir [cygwin]
>> or /c/mydir [msys] and convert it to c:\mydir, and then it will call the
>> executable named as the first (non-option) argument.
>> 
>> So basically on cygwin configure will set
>> CC=/cygdrive/c/mydir/build/fixpath.exe -c /cygdrive/c/msdev/bin/cl.exe
>> The -c to fixpath means "use cygwin mode".
>> 
>> I've seen build problems before with hotspot producing compile lines
>> where fixpath is missing the first argument to
>> /cygdrive/c/msdev/bin/cl.exe, so it seems we're trying to compile with
>> fixpath. This has typically been due to a problem of properly locating
>> the cl.exe compiler. Can you check the configure output and see if
>> cl.exe have been located and found in the proper place?
>> 
>> However, after the msys fixes, we now start with an argument -c or -m,
>> but this seems to be missing as well here, which seems very strange. Do
>> you have some mismatch between the hotspot repo and the top-level repo?
>> 
>> If you look at the generated spec.gmk, what does the line CC say?
>> 
>>> This never was an issue before, what has changed here?
>> I'm guessing either msys support or the cl.exe dection rewrite.
>>> 
>>> This failure will hold up any integration of the build-infra work into
>>> jdk8/build
>> 
>> I realize that. Overall, I feel that we have a sub-optimal workflow for
>> pushing stuff into mainline. For pushing to mainline, we should declare
>> a point in the source code at which we think the code is good enough to
>> go into mainline, try it out on JPRT, make a webrev, and then only make
>> changes that are needed to fix issues found by JPRT or the code review.
>> 
>> On the other hand, we still need to keep development going, and since
>> the producure above can take days or in worst case weeks, like the
>> latest round, we can't just freeze build-infra.
>> 
>> I don't have a good suggestion here. Is it possible to work with
>> branches in mercurial? Can we set a tag in mercurial and then work with
>> a set of patches for the changes needed from that tag?
>> 
>> /Magnus