Fwd: Heads up: Integrating lambda-related changes into jdk8/jdk8

2013-07-16 Thread Jonathan Gibbons 

Build folk,

Is there a way we could put a file in each repo containing the ids of 
the minimum required changeset of other repos?


It would then surely be a simple consistency check to verify that all 
the repos involved in a build meet the minimum level of functionality.


-- Jon


 Original Message 
Subject:Heads up: Integrating lambda-related changes into jdk8/jdk8
Date:   Tue, 16 Jul 2013 13:42:04 -0600
From:   Alejandro E Murillo 
Organization:   Oracle Corporation
To: jdk8-...@openjdk.java.net



Later today I plan to push the hs25-b41 snapshot into jdk8 master [1]
,
along with the fix for 8016281
. This push includes
lambda-related changes that will
create lambda-related incompatibilities with class files compiled with
earlier
JDK 8 versions. See [2]
 for
more details.

Once the changes have been integrated, the hotspot, langtools and jdk
repos must match - i.e., either all must have these changes or not have
any of them.
A JDK with mismatched repos may build, but some lambda-related functionality
might not work properly (again, see [2]
 for
details of the symptoms).

After we integrate, If you do pull, make sure to pull all: hotspot,
langtools and jdk,
and to build all


[1] http://hg.openjdk.java.net/jdk8/jdk8/
[2] http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010449.html

Thanks

--
Alejandro

hg: jdk8/build/langtools: 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle; ...

2013-07-16 Thread david . katleman 
Changeset: 39ec5d8a691b
Author:mcimadamore
Date:  2013-07-11 14:07 +0100
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/39ec5d8a691b

8016281: The SAM method should be passed to the metafactory as a MethodType not 
a MethodHandle
8020010: Move lambda bridge creation from metafactory and VM to compiler
Summary: langtools/javac component of the bridge support and MethodType vs. 
MethodHandle changes.
Reviewed-by: jjg, vromero, briangoetz, forax
Contributed-by: robert.fi...@oracle.com

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/util/Names.java
+ test/tools/javac/generics/bridges/Bridge.java
+ test/tools/javac/generics/bridges/BridgeHarness.java
+ test/tools/javac/generics/bridges/Bridges.java
+ test/tools/javac/generics/bridges/tests/TestBridgeWithDefault.java
+ 
test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical01.java
+ 
test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical02.java
+ test/tools/javac/generics/bridges/tests/TestNoBridgeInSiblingsSuper.java
+ test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges01.java
+ test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges02.java
+ test/tools/javac/lambda/bridge/TestMetafactoryBridges.java
! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java
! test/tools/javac/lambda/methodReference/BridgeMethod.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java

hg: jdk8/build/jdk: 2 new changesets

2013-07-16 Thread david . katleman 
Changeset: f83794805201
Author:mcimadamore
Date:  2013-07-11 14:02 +0100
URL:   http://hg.openjdk.java.net/jdk8/build/jdk/rev/f83794805201

8016281: The SAM method should be passed to the metafactory as a MethodType not 
a MethodHandle
8020010: Move lambda bridge creation from metafactory and VM to compiler
Summary: JDK/metafactory component of the bridge fix and and MethodType vs. 
MethodHandle changes.
Reviewed-by: twisti, briangoetz, forax
Contributed-by: robert.fi...@oracle.com

! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/LambdaMetafactory.java
! src/share/classes/java/lang/invoke/SerializedLambda.java

Changeset: 6a099a36589b
Author:katleman
Date:  2013-07-16 15:16 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/jdk/rev/6a099a36589b

Merge

hg: jdk8/build/hotspot: 33 new changesets

2013-07-16 Thread david . katleman 
Changeset: ea4d24c1e0c6
Author:amurillo
Date:  2013-07-04 14:56 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ea4d24c1e0c6

8019934: new hotspot build - hs25-b41
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: f323bbb0e6c1
Author:coleenp
Date:  2013-07-03 13:45 -0400
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f323bbb0e6c1

8019833: Wrong JNI error code for preexisting JVM
Summary: Return the appropriate JNI error message (instead of the generic one) 
when the JVM is already started
Reviewed-by: coleenp, hseigel
Contributed-by: sylves...@debian.org

! src/share/vm/prims/jni.cpp

Changeset: 5f7a4367c787
Author:zgu
Date:  2013-07-04 06:24 -0400
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5f7a4367c787

8016074: NMT: assertion failed: assert(thread->thread_state() == from) failed: 
coming from wrong thread state
Summary: Uses os::NakedYield() on Solaris instead of os::yield_all()
Reviewed-by: acorn, coleenp, hseigel

! src/share/vm/services/memTracker.hpp

Changeset: a55aa67bce1a
Author:zgu
Date:  2013-07-04 04:03 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a55aa67bce1a

Merge


Changeset: 59b052799158
Author:dcubed
Date:  2013-07-04 21:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/59b052799158

8015884: runThese crashed with SIGSEGV, hs_err has an error instead of 
stacktrace
Summary: Dl_info struct should only be used if dladdr() has returned non-zero 
(no errors) and always check the dladdr() return value; Dl_info.dli_sname and 
Dl_info.dli_saddr fields should only be used if non-NULL; update/improve 
runtime/6888954/vmerrors.sh test
Reviewed-by: dsamersoff, zgu, hseigel, coleenp

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.hpp
! src/os/windows/vm/os_windows.inline.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/debug.hpp
! test/runtime/6888954/vmerrors.sh

Changeset: 93e6dce53ba7
Author:fparain
Date:  2013-07-05 08:26 +
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/93e6dce53ba7

8016465: The hs_err file gets wrong name
Reviewed-by: dcubed, dholmes, rdurbin

! src/share/vm/utilities/vmError.cpp

Changeset: cc5b7915104e
Author:fparain
Date:  2013-07-05 08:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cc5b7915104e

Merge


Changeset: cf9d71d3e474
Author:iklam
Date:  2013-07-08 10:58 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cf9d71d3e474

8016903: Thread::_handle_area initial size too big
Summary: Changed initial size to Chunk::tiny_size (216 bytes)
Reviewed-by: coleenp, dholmes, sspitsyn

! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/handles.hpp

Changeset: 71180a6e5080
Author:jiangli
Date:  2013-07-03 17:26 -0400
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/71180a6e5080

7133260: AllocationProfiler uses space in metadata and doesn't seem to do 
anything useful.
Summary: Remove -Xaprof and Klass::_alloc_count & ArrayKlass::_alloc_size.
Reviewed-by: stefank, coleenp

! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java
! 
src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! 
src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/defNewGeneration.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/sharedHeap.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
- src/share/vm/runtime/aprofiler.cpp
- src/share/vm/runtime/aprofiler.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: fa6929d0b0a9
Author:jiangli
Date:  2013-07-08 14:21 -0400
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fa6929d0b0a9

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 3c7b4b7b2625
Author:jiangli
Date:  2013-07-08 14:53 -0700

Re: RFR: 8015759: hotspot changes needed to compile with Visual Studio 2012

2013-07-16 Thread Yumin Qi 

Filed: https://jbs.oracle.com/bugs/browse/JDK-8020622

Thanks
Yumin
On 7/16/2013 9:21 AM, Tim Bell wrote:

Hi Yumin:

Thanks for looking at this.

The patch works fine when using build.bat to build hotspot on 
Windows, there is one issue with create.bat, which will fail to 
create project file for VS2012.
  I tried to work this around to create a VS2010 project, see URL: 
http://javaweb.us.oracle.com/~yqi/webrev/vs2012build/ 

  The only two files: create.bat and rules.make changed for this 
purpose.


  The created project files, for i486, open with VS2012 OK, but 
amd-64 will hang, I have no time to check the detail why it hangs.
  This may be need addressed in a separate bug. I am OK with the 
current changes, it works fine for build.


Please file a new bug against build.bat.

In my experience, moving from VS2010 to VS2012 is a one-way trip. The 
project files have changed format considerably, so once you move 
forward you cannot go back on that source tree without reverting the 
changes.  It has been a while, but I recall build.bat is doing some 
clever things that rely on the internal format of the VS files, and if 
so it will need to be updated.


Tim

  The failure is because we dont have set properly for the project 
setting, so it default to VC7, which is not right.


Writing .vcproj file: 
D:\yqi\ws\8016538-build\build\vs-amd64\jvm.vcproj

java.lang.NullPointerException
at 
WinGammaPlatformVC7.writeConfiguration(WinGammaPlatformVC7.java:153)
at 
WinGammaPlatformVC7.writeProjectFile(WinGammaPlatformVC7.java:62)

at WinGammaPlatform.createVcproj(WinGammaPlatform.java:270)
at ProjectCreator.main(ProjectCreator.java:93)
NMAKE : fatal error U1077: 'd:\yqi\jdks\windows-i586\bin\java.EXE' : 
return code '0x1'

Stop.


Thanks
Yumin


On 7/15/2013 6:04 PM, David Holmes wrote:

On 15/07/2013 10:29 PM, Tim Bell wrote:

David, Anthony :

Thank you for the review.

David wrote:


Only concern is that we may want to separate out the
make/jprt.properties change, otherwise we can't push this until the
switch to the new compilers has been officially approved. It may be
easier to put the vs2012 support in place first and make the switch
itself later.


I completely agree - separate out the make/jprt.properties change. 
Could

I get a sponsor to push the changes to the other four files to
hotspot-runtime ASAP?


I will sponsor it for you. I'll use the existing patch and revert 
the jprt change.


Thanks,
David



Tim


On 07/14/13 09:20 PM, David Holmes wrote:

Hi Tim,

This looks okay to me.

Only concern is that we may want to separate out the
make/jprt.properties change, otherwise we can't push this until the
switch to the new compilers has been officially approved. It may be
easier to put the vs2012 support in place first and make the switch
itself later.

David

On 13/07/2013 9:51 PM, Tim Bell wrote:

Hello everyone-

Many thanks for the early feedback on this JDK8 hotspot + VS2012
project.

A revised webrev is here:

http://cr.openjdk.java.net/~tbell/8015759/hotspot/webrev.01/

These changes build and pass all of the standard 119 tests (as 
listed in
the jprt.properties file - see below) when using VS2012 and also 
using

VS2010.

Thanks in advance for any feedback-

Tim

*** Build targets:
   windows_i586_5.1-product with attributes compiler=VS2010 (or 
i586_6.1

VS2012)
   windows_i586_5.1-fastdebug with attributes compiler=VS2010 (or
i586_6.1 VS2012)
   windows_x64_5.2-product with attributes compiler=VS2010 (or 
i586_6.1

VS2012)
   windows_x64_5.2-fastdebug with attributes compiler=VS2010 (or
i586_6.1 VS2012)

*** Test targets:
   windows_i586-product-c1-jvm98
   windows_i586-product-c2-jvm98
   windows_i586-fastdebug-c1-jvm98
   windows_i586-fastdebug-c2-jvm98
   windows_i586-product-c2-jvm98_nontiered
   windows_i586-fastdebug-c2-jvm98_nontiered
   windows_i586-product-c1-scimark
   windows_i586-product-c2-scimark
   windows_i586-fastdebug-c1-scimark
   windows_i586-fastdebug-c2-scimark
   windows_i586-product-c1-runThese
   windows_i586-product-c2-runThese
   windows_i586-product-c1-runThese_Xcomp
   windows_i586-product-c2-runThese_Xcomp
   windows_i586-fastdebug-c1-runThese_Xshare
   windows_i586-product-c1-GCBasher_SerialGC
   windows_i586-product-c2-GCBasher_SerialGC
   windows_i586-fastdebug-c1-GCBasher_SerialGC
   windows_i586-fastdebug-c2-GCBasher_SerialGC
   windows_i586-product-c1-GCBasher_ParallelGC
   windows_i586-product-c2-GCBasher_ParallelGC
   windows_i586-fastdebug-c1-GCBasher_ParallelGC
   windows_i586-fastdebug-c2-GCBasher_ParallelGC
   windows_i586-product-c1-GCBasher_ParNewGC
   windows_i586-product-c2-GCBasher_ParNewGC
   windows_i586-fastdebug-c1-GCBasher_ParNewGC
   windows_i586-fastdebug-c2-GCBasher_ParNewGC
   windows_i586-product-c1-GCBasher_CMS
   windows_i586-product-c2-GCBasher_CMS
   windows_i586-fastdebug-c1-GCBasher_CMS
   windows_i586-fastdebug-c2-GCBasher_CMS
   windows_i586

Re: RFR: 8015759: hotspot changes needed to compile with Visual Studio 2012

2013-07-16 Thread Tim Bell 

Hi Yumin:

Thanks for looking at this.

The patch works fine when using build.bat to build hotspot on Windows, 
there is one issue with create.bat, which will fail to create project 
file for VS2012.
  I tried to work this around to create a VS2010 project, see URL: 
http://javaweb.us.oracle.com/~yqi/webrev/vs2012build/ 


  The only two files: create.bat and rules.make changed for this purpose.

  The created project files, for i486, open with VS2012 OK, but amd-64 
will hang, I have no time to check the detail why it hangs.
  This may be need addressed in a separate bug. I am OK with the 
current changes, it works fine for build.


Please file a new bug against build.bat.

In my experience, moving from VS2010 to VS2012 is a one-way trip. The 
project files have changed format considerably, so once you move forward 
you cannot go back on that source tree without reverting the changes.  
It has been a while, but I recall build.bat is doing some clever things 
that rely on the internal format of the VS files, and if so it will need 
to be updated.


Tim

  The failure is because we dont have set properly for the project 
setting, so it default to VC7, which is not right.


Writing .vcproj file: 
D:\yqi\ws\8016538-build\build\vs-amd64\jvm.vcproj

java.lang.NullPointerException
at 
WinGammaPlatformVC7.writeConfiguration(WinGammaPlatformVC7.java:153)
at 
WinGammaPlatformVC7.writeProjectFile(WinGammaPlatformVC7.java:62)

at WinGammaPlatform.createVcproj(WinGammaPlatform.java:270)
at ProjectCreator.main(ProjectCreator.java:93)
NMAKE : fatal error U1077: 'd:\yqi\jdks\windows-i586\bin\java.EXE' : 
return code '0x1'

Stop.


Thanks
Yumin


On 7/15/2013 6:04 PM, David Holmes wrote:

On 15/07/2013 10:29 PM, Tim Bell wrote:

David, Anthony :

Thank you for the review.

David wrote:


Only concern is that we may want to separate out the
make/jprt.properties change, otherwise we can't push this until the
switch to the new compilers has been officially approved. It may be
easier to put the vs2012 support in place first and make the switch
itself later.


I completely agree - separate out the make/jprt.properties change. 
Could

I get a sponsor to push the changes to the other four files to
hotspot-runtime ASAP?


I will sponsor it for you. I'll use the existing patch and revert the 
jprt change.


Thanks,
David



Tim


On 07/14/13 09:20 PM, David Holmes wrote:

Hi Tim,

This looks okay to me.

Only concern is that we may want to separate out the
make/jprt.properties change, otherwise we can't push this until the
switch to the new compilers has been officially approved. It may be
easier to put the vs2012 support in place first and make the switch
itself later.

David

On 13/07/2013 9:51 PM, Tim Bell wrote:

Hello everyone-

Many thanks for the early feedback on this JDK8 hotspot + VS2012
project.

A revised webrev is here:

http://cr.openjdk.java.net/~tbell/8015759/hotspot/webrev.01/

These changes build and pass all of the standard 119 tests (as 
listed in
the jprt.properties file - see below) when using VS2012 and also 
using

VS2010.

Thanks in advance for any feedback-

Tim

*** Build targets:
   windows_i586_5.1-product with attributes compiler=VS2010 (or 
i586_6.1

VS2012)
   windows_i586_5.1-fastdebug with attributes compiler=VS2010 (or
i586_6.1 VS2012)
   windows_x64_5.2-product with attributes compiler=VS2010 (or 
i586_6.1

VS2012)
   windows_x64_5.2-fastdebug with attributes compiler=VS2010 (or
i586_6.1 VS2012)

*** Test targets:
   windows_i586-product-c1-jvm98
   windows_i586-product-c2-jvm98
   windows_i586-fastdebug-c1-jvm98
   windows_i586-fastdebug-c2-jvm98
   windows_i586-product-c2-jvm98_nontiered
   windows_i586-fastdebug-c2-jvm98_nontiered
   windows_i586-product-c1-scimark
   windows_i586-product-c2-scimark
   windows_i586-fastdebug-c1-scimark
   windows_i586-fastdebug-c2-scimark
   windows_i586-product-c1-runThese
   windows_i586-product-c2-runThese
   windows_i586-product-c1-runThese_Xcomp
   windows_i586-product-c2-runThese_Xcomp
   windows_i586-fastdebug-c1-runThese_Xshare
   windows_i586-product-c1-GCBasher_SerialGC
   windows_i586-product-c2-GCBasher_SerialGC
   windows_i586-fastdebug-c1-GCBasher_SerialGC
   windows_i586-fastdebug-c2-GCBasher_SerialGC
   windows_i586-product-c1-GCBasher_ParallelGC
   windows_i586-product-c2-GCBasher_ParallelGC
   windows_i586-fastdebug-c1-GCBasher_ParallelGC
   windows_i586-fastdebug-c2-GCBasher_ParallelGC
   windows_i586-product-c1-GCBasher_ParNewGC
   windows_i586-product-c2-GCBasher_ParNewGC
   windows_i586-fastdebug-c1-GCBasher_ParNewGC
   windows_i586-fastdebug-c2-GCBasher_ParNewGC
   windows_i586-product-c1-GCBasher_CMS
   windows_i586-product-c2-GCBasher_CMS
   windows_i586-fastdebug-c1-GCBasher_CMS
   windows_i586-fastdebug-c2-GCBasher_CMS
   windows_i586-product-c1-GCBasher_G1
   windows_i586-product-c2-GCBasher_G1
   windows_i586-fastdebug-c1-GCBasher_G1
   w

Re: autoconf problem

2013-07-16 Thread Michael McMahon 

On 16/07/13 14:42, Volker Simonis wrote:

On Tue, Jul 16, 2013 at 3:02 PM, Tim Bell  wrote:

Hi Michael:



Since my latest sync of jdk8/cpu (today) I can't run configure. I get the
following
error:


Looks like your merge touched some of the .m4 files
(common/autoconf/basics.m4 and common/autoconf/build-performance.m4 to name
two):

Our standard guidance when this happens is to do your merge, and then run

bash common/autoconf/autogen.sh

to recreate the generated-configure.sh file(s).


That's right but you definitely need autoconf in order to do that (as
indicated in the error).


Okay. Thanks!


Notice that you don't necessarily need to run autoconf an the same
system on which you want to run the generated configure script.
If you have a shared workspace, you may for example install autoconf
on a Linux machine and run autogeg.sh there. Afterwards you can run
configure on any other system (i.e. Windows, Mac, Solaris..)

Regards,
Volker


Lastly, commit them as part of your merge.  If you have the closed repos,
there will be two of them.

Tim



$ bash ./configure
Warning: The generated configure file contains changes not present in the
custom generated file.
Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the generated
files.
Error: Cannot continue
mm72272@mm72272-ThinkPad-T420:/export/repos/jdk8-cpu$ bash ./configure
--help
Warning: The generated configure file contains changes not present in the
custom generated file.
Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the generated
files.
Error: Cannot continue

Now, I don't have "autoconf" installed but before I try and continue by
installing it,
I'd like to understand more why this is happening. Any ideas?

Thanks!
Michael

Re: autoconf problem

2013-07-16 Thread Volker Simonis 
On Tue, Jul 16, 2013 at 3:02 PM, Tim Bell  wrote:
> Hi Michael:
>
>
>> Since my latest sync of jdk8/cpu (today) I can't run configure. I get the
>> following
>> error:
>
>
> Looks like your merge touched some of the .m4 files
> (common/autoconf/basics.m4 and common/autoconf/build-performance.m4 to name
> two):
>
> Our standard guidance when this happens is to do your merge, and then run
>
> bash common/autoconf/autogen.sh
>
> to recreate the generated-configure.sh file(s).
>

That's right but you definitely need autoconf in order to do that (as
indicated in the error).

Notice that you don't necessarily need to run autoconf an the same
system on which you want to run the generated configure script.
If you have a shared workspace, you may for example install autoconf
on a Linux machine and run autogeg.sh there. Afterwards you can run
configure on any other system (i.e. Windows, Mac, Solaris..)

Regards,
Volker

> Lastly, commit them as part of your merge.  If you have the closed repos,
> there will be two of them.
>
> Tim
>
>
>> $ bash ./configure
>> Warning: The generated configure file contains changes not present in the
>> custom generated file.
>> Cannot locate autoconf, unable to correct situation.
>> Please install autoconf and run 'bash autogen.sh' to update the generated
>> files.
>> Error: Cannot continue
>> mm72272@mm72272-ThinkPad-T420:/export/repos/jdk8-cpu$ bash ./configure
>> --help
>> Warning: The generated configure file contains changes not present in the
>> custom generated file.
>> Cannot locate autoconf, unable to correct situation.
>> Please install autoconf and run 'bash autogen.sh' to update the generated
>> files.
>> Error: Cannot continue
>>
>> Now, I don't have "autoconf" installed but before I try and continue by
>> installing it,
>> I'd like to understand more why this is happening. Any ideas?
>>
>> Thanks!
>> Michael
>>
>

Re: autoconf problem

2013-07-16 Thread Tim Bell 

Hi Michael:

Since my latest sync of jdk8/cpu (today) I can't run configure. I get 
the following

error:


Looks like your merge touched some of the .m4 files 
(common/autoconf/basics.m4 and common/autoconf/build-performance.m4 to 
name two):


Our standard guidance when this happens is to do your merge, and then run

bash common/autoconf/autogen.sh

to recreate the generated-configure.sh file(s).

Lastly, commit them as part of your merge.  If you have the closed 
repos, there will be two of them.


Tim


$ bash ./configure
Warning: The generated configure file contains changes not present in 
the custom generated file.

Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the 
generated files.

Error: Cannot continue
mm72272@mm72272-ThinkPad-T420:/export/repos/jdk8-cpu$ bash ./configure 
--help
Warning: The generated configure file contains changes not present in 
the custom generated file.

Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the 
generated files.

Error: Cannot continue

Now, I don't have "autoconf" installed but before I try and continue 
by installing it,

I'd like to understand more why this is happening. Any ideas?

Thanks!
Michael

Re: autoconf problem

2013-07-16 Thread Dmitry Samersoff 
Michael,

Try to get fresh workspace or at least run
hg pull -u in the root directory.

get_source.sh not always/doesn't update root folder.

-Dmitry

On 2013-07-16 16:20, Michael McMahon wrote:
> Hi,
> 
> Since my latest sync of jdk8/cpu (today) I can't run configure. I get
> the following
> error:
> 
> $ bash ./configure
> Warning: The generated configure file contains changes not present in
> the custom generated file.
> Cannot locate autoconf, unable to correct situation.
> Please install autoconf and run 'bash autogen.sh' to update the
> generated files.
> Error: Cannot continue
> mm72272@mm72272-ThinkPad-T420:/export/repos/jdk8-cpu$ bash ./configure
> --help
> Warning: The generated configure file contains changes not present in
> the custom generated file.
> Cannot locate autoconf, unable to correct situation.
> Please install autoconf and run 'bash autogen.sh' to update the
> generated files.
> Error: Cannot continue
> 
> Now, I don't have "autoconf" installed but before I try and continue by
> installing it,
> I'd like to understand more why this is happening. Any ideas?
> 
> Thanks!
> Michael
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

autoconf problem

2013-07-16 Thread Michael McMahon 

Hi,

Since my latest sync of jdk8/cpu (today) I can't run configure. I get 
the following

error:

$ bash ./configure
Warning: The generated configure file contains changes not present in 
the custom generated file.

Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the 
generated files.

Error: Cannot continue
mm72272@mm72272-ThinkPad-T420:/export/repos/jdk8-cpu$ bash ./configure 
--help
Warning: The generated configure file contains changes not present in 
the custom generated file.

Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the 
generated files.

Error: Cannot continue

Now, I don't have "autoconf" installed but before I try and continue by 
installing it,

I'd like to understand more why this is happening. Any ideas?

Thanks!
Michael