[8u] jdk8\hotspot\src\os\windows\vm\version.rc(57) : warning RC4003: not enough actual parameters for macro 'STR'
Hi On windows, the jdk8\hotspot\src\os\windows\vm\version.rc at line 57 is missing the HS_COMPANY: BEGIN BLOCK 04b0 BEGIN VALUE CompanyName, XSTR(HS_COMPANY) \0 VALUE FileDescription, XSTR(HS_FILEDESC) \0 VALUE FileVersion, XSTR(HS_DOTVER)\0 VALUE Full Version, XSTR(HS_BUILD_ID) \0 VALUE InternalName, XSTR(HS_INTERNAL_NAME) \0 VALUE LegalCopyright, XSTR(HS_COPYRIGHT) \0 VALUE OriginalFilename, XSTR(HS_FNAME) \0 VALUE ProductName, XSTR(HS_NAME) \0 VALUE ProductVersion, XSTR(JDK_DOTVER) \0 END That is why the resource compiler is producing this warning Z:\JDK\jdk8\hotspot\src\os\windows\vm\version.rc(57) : warning RC4003: not enough actual parameters for macro 'STR' Here the fix to avoid this warning by setting up the HS_COMPANY to the COMPANY_NAME variable in make/windows/build.make Francis --- a/make/windows/build.make +++ b/make/windows/build.make @@ -147,6 +147,8 @@ !endif !endif +HS_COMPANY=$(COMPANY_NAME) + # Following the Web Start / Plugin model here # We can have update versions like 01a, but Windows requires # we use only integers in the file version field. So:
Re: [8] WXP fixes to avoid warning when compiling SA files
Staffan By the way, I am working on the jdk7u... Could you also take in charge the backport to the jdk7u? Francis Le 09/12/2013 13:25, Staffan Larsen a écrit : This change looks good to me. I have created https://bugs.openjdk.java.net/browse/JDK-8029798 for this change, and I can sponsor it. There are currently no open repos for low-priority hotspot changes so I will have to wait before pushing the change. /Staffan On 7 dec 2013, at 18:25, Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Compiling SA files leads to warning because of old or invalid options as below set INCLUDE=C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0A\include;C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0A\include C:\progra~1\micros~2.0\vc\bin\cl.exe @C:\cygwin\tmp\nmE2.tmp clÿ: Ligne de commande warning D9035ÿ: l'option 'GZ' est d‚conseill‚e et sera supprim‚e dans une version ult‚rieure clÿ: Ligne de commande warning D9036ÿ: utilisez 'RTC1' … la place de 'GZ' clÿ: Ligne de commande warning D9035ÿ: l'option 'o' est d‚conseill‚e et sera supprim‚e dans une version ult‚rieure clÿ: Ligne de commande warning D9002ÿ: option '-YX' inconnue ignor‚e clÿ: Ligne de commande warning D9030ÿ: '/Gm' incompatible avec le multitraitementÿ; commutateur /MP ignor‚ sadis.c Here the diff diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make --- a/make/windows/makefiles/sa.make +++ b/make/windows/makefiles/sa.make @@ -94,7 +94,7 @@ SA_LD_FLAGS = bufferoverflowU.lib !endif !else -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D WIN32 -D _WINDOWS -D _DEBUG -D _CONSOLE -D _MBCS -YX -FD -GZ -c +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D WIN32 -D _WINDOWS -D _DEBUG -D _CONSOLE -D _MBCS -FD -RT C1 -c !if $(ENABLE_FULL_DEBUG_SYMBOLS) == 1 SA_CFLAGS = $(SA_CFLAGS) -ZI !endif
[7u] diff fixes for export_debug_jdk in jdk/hotspot/make/Makefile
Hi
The export_debug_jdk target from jdk7u/hotspot/make/Makefile never exports the
Z:\JDK\hsx\jdk7u\hotspot\build\windows\export-windows-i586\debug directories
into
Z:\JDK\hsx\jdk7u\hotspot\build\windows\jdk-windows-i586
but it updates
Z:\JDK\\hsx\jdk7u\hotspot\build\windows\jdk-windows-i586\debug which is
useless...
Francis
Here the fixes:
diff --git a/make/Makefile b/make/Makefile
--- a/make/Makefile
+++ b/make/Makefile
@@ -242,12 +242,11 @@
generic_export
export_fastdebug_jdk::
$(MAKE) BUILD_FLAVOR=$(@:export_%_jdk=%) \
- VM_SUBDIR=$(@:export_%_jdk=%) \
- ALT_EXPORT_PATH=$(JDK_IMAGE_DIR)/$(@:export_%_jdk=%) \
+ VM_SUBDIR=$(@:export_%_jdk=%) ALT_EXPORT_PATH=$(JDK_IMAGE_DIR) \
generic_export
export_debug_jdk::
-$(MAKE) BUILD_FLAVOR=$(@:export_%_jdk=%) VM_SUBDIR=${VM_DEBUG} \
- ALT_EXPORT_PATH=$(JDK_IMAGE_DIR)/$(@:export_%_jdk=%) \
+$(MAKE) BUILD_FLAVOR=$(@:export_%_jdk=%) \
+ VM_SUBDIR=${VM_DEBUG} ALT_EXPORT_PATH=$(JDK_IMAGE_DIR) \
generic_export
Re: [8] WXP fixes to avoid warning when compiling SA files
Staffan Thank you for taking the fixes on your side. Francis Le 09/12/2013 13:25, Staffan Larsen a écrit : This change looks good to me. I have created https://bugs.openjdk.java.net/browse/JDK-8029798 for this change, and I can sponsor it. There are currently no open repos for low-priority hotspot changes so I will have to wait before pushing the change. /Staffan On 7 dec 2013, at 18:25, Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Compiling SA files leads to warning because of old or invalid options as below set INCLUDE=C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0A\include;C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0A\include C:\progra~1\micros~2.0\vc\bin\cl.exe @C:\cygwin\tmp\nmE2.tmp clÿ: Ligne de commande warning D9035ÿ: l'option 'GZ' est d‚conseill‚e et sera supprim‚e dans une version ult‚rieure clÿ: Ligne de commande warning D9036ÿ: utilisez 'RTC1' … la place de 'GZ' clÿ: Ligne de commande warning D9035ÿ: l'option 'o' est d‚conseill‚e et sera supprim‚e dans une version ult‚rieure clÿ: Ligne de commande warning D9002ÿ: option '-YX' inconnue ignor‚e clÿ: Ligne de commande warning D9030ÿ: '/Gm' incompatible avec le multitraitementÿ; commutateur /MP ignor‚ sadis.c Here the diff diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make --- a/make/windows/makefiles/sa.make +++ b/make/windows/makefiles/sa.make @@ -94,7 +94,7 @@ SA_LD_FLAGS = bufferoverflowU.lib !endif !else -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D WIN32 -D _WINDOWS -D _DEBUG -D _CONSOLE -D _MBCS -YX -FD -GZ -c +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D WIN32 -D _WINDOWS -D _DEBUG -D _CONSOLE -D _MBCS -FD -RT C1 -c !if $(ENABLE_FULL_DEBUG_SYMBOLS) == 1 SA_CFLAGS = $(SA_CFLAGS) -ZI !endif
[8] WXP minor fixes for a cleaner compile of c code
Hi
Below are some warnings produced by the build of jdk8.
Z:/JDK/jdk8/jdk/src/share/native/java/lang/Throwable.c(48) : warning C4028:
paramétre formel 3 différent de la déclaration
Z:/JDK/jdk8/jdk/src/windows/native/java/io/WinNTFileSystem_md.c(363) : warning
C4101: 'pathlen': variable locale non référencée
Z:/JDK/jdk8/jdk/src/windows/native/common/jdk_util_md.c(45) : warning C4101:
'ret': variable locale non référencée
Z:/JDK/jdk8/jdk/src/share/bin/java.c(1253) : warning C4101: 'result': variable
locale nonréférencée
Z:/JDK/jdk8/jdk/src/share/bin/parse_manifest.c(196) : warning C4244: 'fonction':
conversion de 'jlong' en 'unsigned int', perte possible de données
And here are the fixes
diff --git a/src/share/bin/java.c b/src/share/bin/java.c
--- a/src/share/bin/java.c
+++ b/src/share/bin/java.c
@@ -1250,7 +1250,6 @@
GetApplicationClass(JNIEnv *env)
{
jmethodID mid;
-jobject result;
jclass cls = GetLauncherHelperClass(env);
NULL_CHECK0(cls);
NULL_CHECK0(mid = (*env)-GetStaticMethodID(env, cls,
diff --git a/src/share/bin/parse_manifest.c b/src/share/bin/parse_manifest.c
--- a/src/share/bin/parse_manifest.c
+++ b/src/share/bin/parse_manifest.c
@@ -193,7 +193,7 @@
return (-1);
if ((buffer = malloc(END_MAXLEN)) == NULL)
return (-1);
-if ((bytes = read(fd, buffer, len)) 0) {
+if ((bytes = read(fd, buffer, (size_t)len)) 0) {
free(buffer);
return (-1);
}
diff --git a/src/share/native/java/lang/Throwable.c
b/src/share/native/java/lang/Throwable.c
--- a/src/share/native/java/lang/Throwable.c
+++ b/src/share/native/java/lang/Throwable.c
@@ -44,7 +44,7 @@
* `this' so you can write 'throw e.fillInStackTrace();'
*/
JNIEXPORT jobject JNICALL
-Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, int
dummy)
+Java_java_lang_Throwable_fillInStackTrace(JNIEnv *env, jobject throwable, jint
dummy)
{
JVM_FillInStackTrace(env, throwable);
return throwable;
diff --git a/src/windows/native/common/jdk_util_md.c
b/src/windows/native/common/jdk_util_md.c
--- a/src/windows/native/common/jdk_util_md.c
+++ b/src/windows/native/common/jdk_util_md.c
@@ -42,7 +42,6 @@
JNIEXPORT HMODULE JDK_LoadSystemLibrary(const char* name) {
HMODULE handle = NULL;
char path[MAX_PATH];
-int ret;
if (GetSystemDirectory(path, sizeof(path)) != 0) {
strcat(path, \\);
diff --git a/src/windows/native/java/io/WinNTFileSystem_md.c
b/src/windows/native/java/io/WinNTFileSystem_md.c
--- a/src/windows/native/java/io/WinNTFileSystem_md.c
+++ b/src/windows/native/java/io/WinNTFileSystem_md.c
@@ -360,7 +360,6 @@
jobject file)
{
jint rv = 0;
-jint pathlen;
WCHAR *pathbuf = fileToNTPath(env, file, ids.path);
if (pathbuf == NULL)
Re: [8]: help on PKCS#11 tests build
Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou mike.dui...@oracle.com: On Dec 4 2013, at 06:06 , Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
There are 6 dlls in the test directory ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll Francis Le 05/12/2013 03:16, Bradford Wetmore a écrit : IIRC, and in case it wasn't clear from reading the responses, the permission changes are done by the Makefiles (e.g. jdk/test/Makefile:193), and not by JTREG itself. I agree with Jon's comment, perhaps a .dll copy to the temporary working directory is in order. That would save people trying to figure out why their tests are failing when running under a .hg directory with the makefiles, or when using JTREG directly. I'm not sure how many .dlls there are in the test dirs (including closed where most probably live), but should probably be done all together instead of by functional area. Brad On 12/4/2013 10:40 AM, Jonathan Gibbons wrote: It should also be the case that the tests should run if the entire test/ directory (all files and directories) were readonly, so if code is modifying files in place or creating new files anywhere in the test directory, that should be regarded as a Bad Thing and fixed. -- Jon On 12/04/2013 10:27 AM, Francis ANDRE wrote: Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou mike.dui...@oracle.com: On Dec 4 2013, at 06:06 , Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: Le roi est mort, vive le roi!
Hi Staffan Le 25/11/2013 08:53, Staffan Larsen a écrit : The top level make produces a full jdk here: Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image The hotspot make produces a full jdk here : Z:\JDK\jdk8\hotspot\build\windows\jdk-windows-i586 The hotspot create.bat produces a JVM here: Z:\JDK\jdk8\hotspot\build\vs-i486\compiler1 create.bat has only one parameter: the bootstrap jdk and thus does not take into account the configure-based top-level files. Moreover when using an official public jdk7 release as the jdk1.7.0_45 as the bootstrap jdk of jdk8, the produced jvm.vxproj does not work as the changeset associated with the JDK 8016019 are not back ported to the jdk1.7.0_45 release. So I am wondering what specific parameters hotspot developers are using to test their changes under WXP/W7 for the jdk8 hotspot? The visual studio projects are not the official way to build hotspot. They are provided as a nice-to-have feature that developers on windows maintain. The official way to build on all platforms is to use the makefiles. Staffan, while the official way to build on all platforms is to use the makefiles, it does not make sense when talking about debugging, testing and developing a major, large, multi layered C++ application like hotspot. To make it short, VisualStudio C++ is to c++ what Netbeans or Eclipse are for Java, a mandatory powerful IDE for developping large and complex application. Can you image to code, develop, debug, test a multi-threaded java application fo 250 kilo lines without Netbeans, just with vi, makefiles and some additional tools... I do not think so... So, it is the same for hotspot on WXP/W7! Thus, if as I understand well, WXP/W7/ X86/X64 are strategic platfoms for Oracle in providing a fully certified and supported Java environment, then the nice-to-have feature is not at level of the mission. The generation of the jvm.vxproj cannot be a second level citizen but should be as good as the generation of the jdk, fully maintained and integrated as new features, way fo building the new build system and so on are added, modified or deleted Francis /Staffan Francis David - Francis the jdk8 build system, but what is the old one? Francis Le 18/11/2013 19:02, Magnus Ihse Bursie a écrit : So, finally it has happened. The old build system is now removed. The patch was just submitted to the tl forest, from where it will move to master in a few days. If you have personal scripts that are using hard-coded makefile references, you might need to update them. Thanks to everyone who helped this major project become reality: Fredrik, Erik, Kelly, Tim, Jonas, ... /Magnus
Re: Le roi est mort, vive le roi!
David create.bat has only one parameter: the bootstrap jdk and thus does not take into account the configure-based top-level files. Moreover when using an official public jdk7 release as the jdk1.7.0_45 as the bootstrap jdk of jdk8, the produced jvm.vxproj does not work as the changeset associated with the JDK 8016019 are not back ported to the jdk1.7.0_45 release. So I am wondering what specific parameters hotspot developers are using to test their changes under WXP/W7 for the jdk8 hotspot? Most developers don't use create.bat or the vs projects. I am desesperated by your remark, really David - Francis David - Francis the jdk8 build system, but what is the old one? Francis Le 18/11/2013 19:02, Magnus Ihse Bursie a écrit : So, finally it has happened. The old build system is now removed. The patch was just submitted to the tl forest, from where it will move to master in a few days. If you have personal scripts that are using hard-coded makefile references, you might need to update them. Thanks to everyone who helped this major project become reality: Fredrik, Erik, Kelly, Tim, Jonas, ... /Magnus
Re: Le roi est mort, vive le roi!
Mike Le 19/11/2013 19:14, Mike Duigou a écrit : Early in jdk8 development it used the same build system as jdk7. A new build system was developed and eventually replaced the old build system. The removal in this changeset removed the obsolete legacy build system. There are no plans to backport the new build system to java 7. Just to confirm my understanding, when Magnus or yourself speak about the old system as the jdk7 one, you are talking about the build of the subdirectory jdk8/jdk because the jdk8/hotspot is the same as in jdk7. By the way, I am wondering in the new system how you are planning the support the create.bat and the generation of the jcm.vxproj by ProjectCreator. VisualStudio C++ is a mandatory tool for testing, understanding and debugging hotspot. So what about the old hotspot build under jdk8? Francis the jdk8 build system, but what is the old one? Francis Le 18/11/2013 19:02, Magnus Ihse Bursie a écrit : So, finally it has happened. The old build system is now removed. The patch was just submitted to the tl forest, from where it will move to master in a few days. If you have personal scripts that are using hard-coded makefile references, you might need to update them. Thanks to everyone who helped this major project become reality: Fredrik, Erik, Kelly, Tim, Jonas, ... /Magnus
Re: Le roi est mort, vive le roi!
David Le 25/11/2013 02:55, David Holmes a écrit : On 25/11/2013 1:46 AM, Francis ANDRE wrote: Mike Le 19/11/2013 19:14, Mike Duigou a écrit : Early in jdk8 development it used the same build system as jdk7. A new build system was developed and eventually replaced the old build system. The removal in this changeset removed the obsolete legacy build system. There are no plans to backport the new build system to java 7. Just to confirm my understanding, when Magnus or yourself speak about the old system as the jdk7 one, you are talking about the build of the subdirectory jdk8/jdk because the jdk8/hotspot is the same as in jdk7. Not quite. The hotspot build system was not rewritten to require the configure-based top-level build, but it was modified to be aware of, and work with, a configure-based top-level build. A lot of hotspot developers only build hotspot, not the full JDK. So David, how do they test their changes to hotspot?? with jtreg? another tool? By the way, I am wondering in the new system how you are planning the support the create.bat and the generation of the jcm.vxproj by ProjectCreator. VisualStudio C++ is a mandatory tool for testing, understanding and debugging hotspot. So what about the old hotspot build under jdk8? Updates to those windows specific parts of the hotspot build have taken place as problems are detected. If there is something specific that is currently an issue then a bug needs to be filed against hotspot-build. The hotspot team generally handles this not the build team. The top level make produces a full jdk here: Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image The hotspot make produces a full jdk here : Z:\JDK\jdk8\hotspot\build\windows\jdk-windows-i586 The hotspot create.bat produces a JVM here: Z:\JDK\jdk8\hotspot\build\vs-i486\compiler1 create.bat has only one parameter: the bootstrap jdk and thus does not take into account the configure-based top-level files. Moreover when using an official public jdk7 release as the jdk1.7.0_45 as the bootstrap jdk of jdk8, the produced jvm.vxproj does not work as the changeset associated with the JDK 8016019 are not back ported to the jdk1.7.0_45 release. So I am wondering what specific parameters hotspot developers are using to test their changes under WXP/W7 for the jdk8 hotspot? Francis David - Francis the jdk8 build system, but what is the old one? Francis Le 18/11/2013 19:02, Magnus Ihse Bursie a écrit : So, finally it has happened. The old build system is now removed. The patch was just submitted to the tl forest, from where it will move to master in a few days. If you have personal scripts that are using hard-coded makefile references, you might need to update them. Thanks to everyone who helped this major project become reality: Fredrik, Erik, Kelly, Tim, Jonas, ... /Magnus
[8] langtools DocCommentTester.java:109: error: cannot find symbol
Hello
I am running the langtools test suite with
/cygdrive/c/cygwin/usr/local/bin/make -k -C ../langtools/test
JT_JAVA=/cygdrive/Z/JDK/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
TEST=jtreg jtreg
and got many compiles error. I think
jdk8\build\windows-x86-normal-server-release\langtools\classes\com\sun\source\util
directory is missing from the classpath but dot know how to fix it.
Any thought?
Francis
FrancisANDRE@idefix /cygdrive/Z/JDK/jdk8
$ hg tip
changeset: 908:0a6db1aac998
tag: tip
user:cl
date:Thu Nov 21 09:22:41 2013 -0800
summary: Added tag jdk8-b117 for changeset a4afb0a8d55e
--
TEST: tools/javac/doctree/AttrTest.java
JDK under test:
(Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image)
openjdk version 1.8.0-internal
OpenJDK Runtime Environment (build
1.8.0-internal-francisandre_2013_11_22_07_15-b00)
OpenJDK Server VM (build 25.0-b59, mixed mode)
ACTION: build -- Failed. Compilation failed: Compilation failed
REASON: User specified action: run build DocCommentTester
TIME: 1.75 seconds
messages:
command: build DocCommentTester
reason: User specified action: run build DocCommentTester
elapsed time (seconds): 1.75
ACTION: compile -- Failed. Compilation failed: Compilation failed
REASON: .class file out of date or does not exist
TIME: 1.734 seconds
messages:
command: compile -XDignore.symbol.file=true
Z:\JDK\jdk8\langtools\test\tools\javac\doctree\DocCommentTester.java
reason: .class file out of date or does not exist
elapsed time (seconds): 1.734
rerun:
'PATH=C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE;C:\Program
Files\Microsoft Visual Studio 10.0\VC\BIN;C:\Program Files\Microsoft Visual
Studio
10.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\Program
Files\Microsoft Visual Studio 10.0\VC\VCPackages;C:\Program Files\HTML Help
Workshop;C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0
Tools;C:\Program Files\Microsoft
SDKs\Windows\v7.0A\bin;C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS\System32\Wbem;C:\Program
Files\Microsoft Visual Studio 10.0\Common7\IDE;C:\Program Files\Microsoft Visual
Studio 10.0\VC\BIN;C:\Program Files\Microsoft Visual Studio
10.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\Program
Files\Microsoft Visual Studio 10.0\VC\VCPackages;C:\Program Files\Microsoft
SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools;C:\Program Files\Microsoft
SDKs\Windows\v7.0A\bin;C:\Program Files\Apache Software
Foundation\apache-ant-1.8.4\bin;C:\Program Files\Apache Software
Foundation\apache-maven-3.0.3\bin' \
SystemDrive=C: \
'SystemRoot=C:\WINDOWS' \
'TEMP=C:\cygwin\tmp' \
'TMP=C:\cygwin\tmp' \
'windir=C:\WINDOWS' \
'Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image\bin\javac'
\
-J-Xmx768m \
-J-Dtest.vm.opts=-Xmx768m \
-J-Dtest.class.path.prefix='Z:\JDK\jdk8\langtools\build\windows-i586\test\langtools\jtreg\JTwork\classes\1\tools\javac\doctree;Z:\JDK\jdk8\langtools\test\tools\javac\doctree'
\
-J-Dtest.jdk='Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image'
\
-J-Dtest.timeout.factor=1.0 \
-J-Dtest.src.path='Z:\JDK\jdk8\langtools\test\tools\javac\doctree' \
-J-Dtest.compiler.opts= \
-J-Dcompile.jdk='Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image'
\
-J-Dtest.classes='Z:\JDK\jdk8\langtools\build\windows-i586\test\langtools\jtreg\JTwork\classes\1\tools\javac\doctree'
\
-J-Dtest.class.path='Z:\JDK\jdk8\langtools\build\windows-i586\test\langtools\jtreg\JTwork\classes\1\tools\javac\doctree'
\
-J-Dtest.java.opts= \
-J-Dtest.src='Z:\JDK\jdk8\langtools\test\tools\javac\doctree' \
-J-Dtest.tool.vm.opts=-J-Xmx768m \
-d
'Z:\JDK\jdk8\langtools\build\windows-i586\test\langtools\jtreg\JTwork\classes\1\tools\javac\doctree'
-classpath
'Z:\JDK\jdk8\langtools\build\windows-i586\test\langtools\jtreg\JTwork\classes\1\tools\javac\doctree;Z:\JDK\jdk8\langtools\test\tools\javac\doctree;Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image\lib\tools.jar'
-sourcepath 'Z:\JDK\jdk8\langtools\test\tools\javac\doctree'
-XDignore.symbol.file=true
'Z:\JDK\jdk8\langtools\test\tools\javac\doctree\DocCommentTester.java'
direct:
Z:\JDK\jdk8\langtools\test\tools\javac\doctree\DocCommentTester.java:109: error:
cannot find symbol
static abstract class DeclScanner extends TreePathScannerVoid, Void {
^
symbol: class TreePathScanner
location: class DocCommentTester
Z:\JDK\jdk8\langtools\test\tools\javac\doctree\DocCommentTester.java:113: error:
cannot find symbol
public Void visitClass(ClassTree tree, Void ignore) {
[8]: help on PKCS#11 tests build
Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.init(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:313) ... 9 more
Re: [7u]: help on jdk/make/common/shared/Defs-windows.gmk
Erik How are you invoking the build to cause this error? Are you explicitly setting ALT_OUTPUTDIR? I am invoking just: make sanity without explicitly setting ALT_OUTPUTDIR. What is the path to your workspace? FrancisANDRE@idefix /cygdrive/Z/JDK/jdk7u $ hg path default = http://hg.openjdk.java.net/jdk7u/jdk7u FrancisANDRE@idefix /cygdrive/Z/JDK/jdk7u $ hg root /cygdrive/Z/JDK/jdk7u I extracted the relevant commands from the jdk/make/common/shared/Defs-windows.gmk into the joined test.mk file if one runs make -f test.mk with $(if $(word 2,$1) at line 72, one gets $ make -f test.mk *OUTPUTDIR=./build/windows-i586** **ABS_OUTPUTDIR=* ALT_HOTSPOT_IMPORT_PATH=Z:/JDK/jdk7u/build/windows-i586/hotspot/import _HOTSPOT_IMPORT_PATH2= _HOTSPOT_IMPORT_PATH3= HOTSPOT_IMPORT_PATH=Z:/JDK/jdk7u/build/windows-i586/hotspot/import SYSTEMROOT=C:WINDOWS xSYSTEMROOT=C:/WINDOWS _system_root=C:/WINDOWS FOO=Z:/JDK/jdk7u/build/windows-i586 BAR=C:/WINDOWS if one runs make -f test.mk with $(if $(word 1,$1) at line 72, one gets $ make -f test.mk *OUTPUTDIR=./build/windows-i586** **ABS_OUTPUTDIR=Z:/JDK/jdk7u/build/WINDOW~1* ALT_HOTSPOT_IMPORT_PATH=Z:/JDK/jdk7u/build/windows-i586/hotspot/import _HOTSPOT_IMPORT_PATH2= _HOTSPOT_IMPORT_PATH3= HOTSPOT_IMPORT_PATH=Z:/JDK/jdk7u/build/WINDOW~1/hotspot/import SYSTEMROOT=C:WINDOWS xSYSTEMROOT=C:/WINDOWS _system_root=C:/WINDOWS FOO=Z:/JDK/jdk7u/build/WINDOW~1 BAR=C:/WINDOWS in both case, OUTPUTDIR is a relative path as ./build/windows-i586, but only the second computes properly the ABS_OUTPUTDIR as Z:/JDK/jdk7u/build/WINDOW~1. In the first case, ABS_OUTPUTDIR is empty with leads to the error ERROR: Trouble with the absolute path for OUTPUTDIR Le 20/11/2013 10:47, Erik Joelsson a écrit : The way I understand it $(if $(word 2,$1) is a check for whitespace in the input parameter. It's an optimization to avoid executing cygpath when it's not needed. The MixedPath macro cannot be used if the path contains a space. It also doesn't convert to an absolute path, just replacing cygwin specific paths with driveletter paths. The unfortunate effect of this is that FullPath behaves differently depending on if the path contains a space. How are you invoking the build to cause this error? Are you explicitly setting ALT_OUTPUTDIR? What is the path to your workspace? /Erik On 2013-11-15 18:37, Francis ANDRE wrote: Hi I am trying to fix the following error $ make sanity jdk/make/common/shared/Defs.gmk:563: *** ERROR: Trouble with the absolute path for OUTPUTDIR './bui ld/windows-i586'. Stop. and found the following code in jdk/make/common/shared/Defs-windows.gmk, line 109 define FullPath $(if $(word 2,$1),$(shell $(CYGPATH_CMD) $1 2 $(DEV_NULL)),$(call MixedPath,$(realpath $(subst ,,$1 endef Can someone explain me what use case is covered by the $(word 2,$1) in the previous statement? The error ERROR: Trouble with the absolute path for OUTPUTDIR can be fixed by replacing $(word 2,$1) by $(word 1,$1) but I cannot find a usage for the $(word 2,$1) Francis CYGWIN_HOME := C:/Cygwin DEV_NULL = /dev/null CYGPATH_CMD = cygpath -a -s -m define PwdPath $(shell cd $1 2 $(DEV_NULL) pwd) endef define AbsPwdPathCheck $(shell cd .. 2 $(DEV_NULL) cd $1 2 $(DEV_NULL) pwd) endef # Checks an ALT value for spaces (should be one word), # warns and returns Check_ALT_$1 if spaces define AltCheckSpaces $(if $(word 2,$($1)),$(warning WARNING: Value of $1 contains a space: '$($1)', check or set ALT_$1)Check_ALT_$1,$($1)) endef # Checks an ALT value for empty, warns and returns Check_ALT_$1 if empty define AltCheckValue $(if $($1),$($1),$(warning WARNING: Value of $1 cannot be empty, check or set ALT_$1)Check_ALT_$1) endef # Checks any value for empty, warns and returns $2 if empty define CheckValue $(if $($1),$($1),$(warning WARNING: Value of $1 cannot be empty, will use '$2')$2) endef # Prefix for a utility prefix path, if empty leave alone, otherwise end with a / define PrefixPath $(if $1,$(subst //,/,$1/),) endef define DirExists $(shell if [ -d $1 ]; then echo $1; elif [ -d $2 ]; then echo $2; else echo $3; fi) endef # Select a directory if it exists, or the alternate 2, or the alternate 3, or the alternate 4 define DirExists4 $(shell \ if [ -d $1 ]; then \ echo $1; \ elif [ -d $2 ]; then \ echo $2; \ elif [ -d $3 ]; then \ echo $3; \ else \ echo $4; \ fi) endef define ToUpper $(subst a,A,$(subst b,B,$(subst c,C,$(subst d,D,$(subst e,E,$(subst f,F,\ $(subst g,G,$(subst h,H,$(subst i,I,$(subst j,J,$(subst k,K,$(subst l,L,\ $(subst m,M,$(subst n,N,$(subst o,O,$(subst p,P,$(subst q,Q,$(subst r,R,\ $(subst s,S,$(subst t,T,$(subst u,U,$(subst v,V,$(subst w,W,$(subst x,X,\ $(subst y,Y,$(subst z,Z,$1)) endef # All possible drive letters drives=a b c d e f g h i j k l m n o p q r s t u v w x y z #drives=A B C D E F G H I J K L M N O P Q R S T U V W X Y Z # Convert /cygdrive/ paths to the mixed style
Re: RFR: Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop
Le 20/11/2013 08:37, Ivan Krylov a écrit : I went through the exercise of building openjdk 7-8 on Windows and concur it isn't trivial. But google helps and I found very the helpful Volker's blogpost very quickly. A build system should be ideally self contained, including its documentation. This means that there should be no need to gogol for finding out additional help. There is already the problem of non proprietary additional software for building OpenJDK and centralizing all pieces in a single place seems to me a good idea. Moreover, the day the Simonis'blog is removed for any reason, one looses this Window's focused paper... This problem should not be solved by adding extra pointer to workarounds. The build system on Windows should work with the latest Cygwin's make. I think that the openjdk community is big enough to influence and push through all necessary fixes into make. I already exchange with the Cygwin guys for making ksh recognizing windows path for the webrev.ksh script...they said clearly no way... Francis Ivan On 11/19/13 11:05 AM, Francis ANDRE wrote: Hi Dalibor Everybody at Oracle and may be elsewhere knows how difficult is the task of building OpenJDK on WXP/W7. There was even in a previous OpenJDK contest a proposal for making this windows build smoother... Thus, the blog of Volker SIMONIS is really of a great help to avoid loosing time, energy and aspirine for building OpenJDK on Windows. I was specially redevable to Volker on the chapter about the specific version of Make 3.82 which in the standard cygwin delivery does not understand the Windows Letter based path. Without his guide on compiling and running the latest Make out of cygwin, NO ONE, and I repeat, NO ONE can make the OpenJDK because it fails without a clear and understandable errors. Moreover, when asking the build list about those errors, no one answers because no one can imagine that the Cygwin make cannot manage Windows letter based path. So, yes, adding the blog of Wolker SIMONIS or may be a reformatted text*is a major help for building OpenJDK on windows*. Please, reconsider your position on adding this blog post as a README file. Francis Le 18/11/2013 20:11, Dalibor Topic a écrit : On 10/6/13 8:37 PM, Francis ANDRE wrote: Hi I submit this patch for review for this Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop The webrev.ksh is broken on WXP/Cygwin. So I am providing here the hg outgoing report as well as the new file README-Windows-Cygwin-VS2010 I don't think that it's necessary to include blog posts in the source code archives. ;) cheers, dalibor topic
Re: RFR: Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop
Hi Erik Le 20/11/2013 11:06, Erik Joelsson a écrit : We identified cygwin make's inability to handle driveletter paths as one of the big problems with the old build system when starting the build-infra work for jdk8. So we designed the new build system to not use any mixed paths to avoid this problem. Yes, you are right for the building of the jdk but that's only a part of the whole job. When talking about tests -- jtreg in particular --, you need to go back to the path handled by Java on windows and in that case, cygwin path does not work at all, only windows path with letter and '/' are working... So mixed path is a good compromise on windows for building, testing and delivering the full product The problem with driveletter paths is also stated in the current README-builds.html and a number of workarounds are mentioned. True, but all specific turn arounds for windows and cygwin and dependent third party software builds are disseminated all along the README-builds.html, which are making the build not so obvious. Even if one dislikes Windows, it is a so important platform for the Java ecosystem that it would make sense, from my point of view, to have a specific, Windows focused README... I agree that documentation can always be improved however, and would encourage suggesting improvements to the current documentation rather than duplicating and making it redundant. Ok..got the point /Erik On 2013-11-20 08:37, Ivan Krylov wrote: I went through the exercise of building openjdk 7-8 on Windows and concur it isn't trivial. But google helps and I found very the helpful Volker's blogpost very quickly. This problem should not be solved by adding extra pointer to workarounds. The build system on Windows should work with the latest Cygwin's make. I think that the openjdk community is big enough to influence and push through all necessary fixes into make. Ivan On 11/19/13 11:05 AM, Francis ANDRE wrote: Hi Dalibor Everybody at Oracle and may be elsewhere knows how difficult is the task of building OpenJDK on WXP/W7. There was even in a previous OpenJDK contest a proposal for making this windows build smoother... Thus, the blog of Volker SIMONIS is really of a great help to avoid loosing time, energy and aspirine for building OpenJDK on Windows. I was specially redevable to Volker on the chapter about the specific version of Make 3.82 which in the standard cygwin delivery does not understand the Windows Letter based path. Without his guide on compiling and running the latest Make out of cygwin, NO ONE, and I repeat, NO ONE can make the OpenJDK because it fails without a clear and understandable errors. Moreover, when asking the build list about those errors, no one answers because no one can imagine that the Cygwin make cannot manage Windows letter based path. So, yes, adding the blog of Wolker SIMONIS or may be a reformatted text*is a major help for building OpenJDK on windows*. Please, reconsider your position on adding this blog post as a README file. Francis Le 18/11/2013 20:11, Dalibor Topic a écrit : On 10/6/13 8:37 PM, Francis ANDRE wrote: Hi I submit this patch for review for this Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop The webrev.ksh is broken on WXP/Cygwin. So I am providing here the hg outgoing report as well as the new file README-Windows-Cygwin-VS2010 I don't think that it's necessary to include blog posts in the source code archives. ;) cheers, dalibor topic
Re: Le roi est mort, vive le roi!
Magnus By the way, what is exactly the old build system??? I am aware of the jdk7u build system, the jdk8 build system, but what is the old one? Francis Le 18/11/2013 19:02, Magnus Ihse Bursie a écrit : So, finally it has happened. The old build system is now removed. The patch was just submitted to the tl forest, from where it will move to master in a few days. If you have personal scripts that are using hard-coded makefile references, you might need to update them. Thanks to everyone who helped this major project become reality: Fredrik, Erik, Kelly, Tim, Jonas, ... /Magnus
Re: Le roi est mort, vive le roi!
Ok, but does this mean that no one is interested in fixing the old jdk7u system? (I posted an help message about [7u]: help on jdk/make/common/shared/Defs-windows.gmk and got no answer, while the fix I am proposing will make the build in jdk7u easier by fixing this error ERROR: Trouble with the absolute path for OUTPUTDIR!!) Francis Le 19/11/2013 19:14, Mike Duigou a écrit : On Nov 19 2013, at 09:26 , Francis ANDRE francis.andre.kampb...@orange.fr wrote: Magnus By the way, what is exactly the old build system??? I am aware of the jdk7u build system, Early in jdk8 development it used the same build system as jdk7. A new build system was developed and eventually replaced the old build system. The removal in this changeset removed the obsolete legacy build system. There are no plans to backport the new build system to java 7. the jdk8 build system, but what is the old one? Francis Le 18/11/2013 19:02, Magnus Ihse Bursie a écrit : So, finally it has happened. The old build system is now removed. The patch was just submitted to the tl forest, from where it will move to master in a few days. If you have personal scripts that are using hard-coded makefile references, you might need to update them. Thanks to everyone who helped this major project become reality: Fredrik, Erik, Kelly, Tim, Jonas, ... /Magnus
Re: 7u40 on WXP/Cygwin: webrev: Is there a java or ant version of webrev?
Hi Magnus This thread is quite an old thread on the webrev/ksh topic and I already told you in a previous thread that the problem was coming from the TortoiseHG that was located in the PATH before the cygwin hg. The real problem is the mix of ksh and TortoiseHG and thus only webrev got this issue because it cannot be run under another shell. TortoiseHG alone works pretty well with cygwin and the gnu make. I would suggest to add in the cygwin section of the README-build.html a line for hg mercurial NameCategoryPackage Description hg.exe Devel binutilsPython based distributed version control system (DVCS) and specify also that the local TortoiseHG binaries be removed from the path. Francis Le 18/11/2013 21:22, Magnus Ihse Bursie a écrit : You should never use dos (or mixed) style paths, like Z:/dev, in Cygwin. Since Cygwin never presents $PWD like that, I suspect the problem is that you have gotten a bad path somewhere, most likely in your hgrc. What does cat .hg/hgrc say? And - importantly - did you clone the repo using hg from Cygwin and not TortoiseHG? The latter does not work well with Cygwin, and could very well end up writing a dos/mixed style path to the hgrc, which would then cause webrev to fail. /Magnus 5 okt 2013 kl. 15:28 skrev Francis ANDRE francis.andre.kampb...@orange.fr: Hi Builders I am really fighting against the triumvira (Cygwin, ksh, webrev.ksh) because of a bug in the cd command of the korn shell under cygwin -- log below --. The cd command prepends the target directory where to go by the current $PWD. cd Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles becomes cd /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles and for sure, the translated directory does not exist. So, it is clear that's not a problem with webrev.ksh but I am stacked with and I have no idea when this problem will be fixed in the Cygwin tool. Thus I am wondering if there is a java or ant version of webrev because I am not able to fix this issue in a 3000+ lines of ksh while that's not a problem in java or ant. Francis $ ksh ./make/scripts/webrev.ksh -v ./make/scripts/webrev.ksh version: 23.18-hg+jbs SCM detected: mercurial Workspace: Z:/DEV/OpenJDK_7u40/hotspot Compare against: http://hg.openjdk.java.net/jdk7u/jdk7u40-dev/hotspot Output to: Z:/DEV/OpenJDK_7u40/hotspot/webrev Output Files: ./make/scripts/webrev.ksh[2899]: cd: /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles: No such file or directory abort: cannot follow file not in parent revision: sa.make make/windows/makefiles/sa.make ./make/scripts/webrev.ksh[2899]: cd: /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles: No such file or directory *** Error: file not in parent or child
Re: RFR: Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop
Hi Dalibor Everybody at Oracle and may be elsewhere knows how difficult is the task of building OpenJDK on WXP/W7. There was even in a previous OpenJDK contest a proposal for making this windows build smoother... Thus, the blog of Volker SIMONIS is really of a great help to avoid loosing time, energy and aspirine for building OpenJDK on Windows. I was specially redevable to Volker on the chapter about the specific version of Make 3.82 which in the standard cygwin delivery does not understand the Windows Letter based path. Without his guide on compiling and running the latest Make out of cygwin, NO ONE, and I repeat, NO ONE can make the OpenJDK because it fails without a clear and understandable errors. Moreover, when asking the build list about those errors, no one answers because no one can imagine that the Cygwin make cannot manage Windows letter based path. So, yes, adding the blog of Wolker SIMONIS or may be a reformatted text*is a major help for building OpenJDK on windows*. Please, reconsider your position on adding this blog post as a README file. Francis Le 18/11/2013 20:11, Dalibor Topic a écrit : On 10/6/13 8:37 PM, Francis ANDRE wrote: Hi I submit this patch for review for this Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop The webrev.ksh is broken on WXP/Cygwin. So I am providing here the hg outgoing report as well as the new file README-Windows-Cygwin-VS2010 I don't think that it's necessary to include blog posts in the source code archives. ;) cheers, dalibor topic
[7u]: help on jdk/make/common/shared/Defs-windows.gmk
Hi I am trying to fix the following error $ make sanity jdk/make/common/shared/Defs.gmk:563: *** ERROR: Trouble with the absolute path for OUTPUTDIR './bui ld/windows-i586'. Stop. and found the following code in jdk/make/common/shared/Defs-windows.gmk, line 109 define FullPath $(if $(word 2,$1),$(shell $(CYGPATH_CMD) $1 2 $(DEV_NULL)),$(call MixedPath,$(realpath $(subst ,,$1 endef Can someone explain me what use case is covered by the $(word 2,$1) in the previous statement? The error ERROR: Trouble with the absolute path for OUTPUTDIR can be fixed by replacing $(word 2,$1) by $(word 1,$1) but I cannot find a usage for the $(word 2,$1) Francis
Re: Help: jdk/make/common/shared/Defs.gmk:563: *** ERROR: Trouble with the absolute path for OUTPUTDIR '
Mike Le 05/11/2013 07:16, Mike Duigou a écrit : Hi Using a fresh copy of the jdk7u repository, and running make -d sanity, I got the error below. Why OUTPUTDIR must be absolute or if it must be absolute, why it is not when running make sanity? In general, using absolute paths always helps for this kind of configuration work. I do not understand your remark. I did not specify anything for OUTPUTDIR, neither on the command line, neither as exported variable. OUTPUT is computed by one of the included makefile and no one should have to specify it by default since by the end, its value is build/windows-i586 relative to the top level directory. It seems to me that OUTPUTDIR is computed in the jdk subdirectory makefiles while it is not in the top level Makefile. Thus, the check that it must be absolute in the included jdk/make/common/shared/Defs.gmk fails. The only way I found to bypass this error is to set ALT_OUTPUTDIR=Z:/JDK/hsx/jdk7u/build/windows-i586 It seems like passing an absolute OUTPUTDIR is the solution and I suspect it should be a /cydrive path not a native path. From my point of view, it seems more a conflicting option setting between the top level single Makefile and all the jdk subdir makefiles. Be aware that it is not possible to build OpenJDK on Windows. There are components and build logic missing (FreeType among them) that would be necessary to build a working JDK. Unless you are working on adding the missing components, attempting to build OpenJDK on Windows is probably destined to be a fruitless endeavour. If you are interested in working on adding support for Windows to OpenJDK builds (as opposed to Oracle Java which does have Windows builds) then the jdk 8 project is probably a more worthwhile direction. Please look at this URL: https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction?force=510 where Volker SIMONIS explains all bits and bytes for building OpenJDK on Windows. This works! Mike Francis FrancisANDRE@idefix /cygdrive/Z/JDK/hsx/jdk7u $ make -d sanity GNU Make 3.82 Built for i686-pc-cygwin Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading makefiles... Reading makefile `Makefile'... Reading makefile `jdk/make/common/shared/Defs-control.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Platform.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Defs.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Defs-utils.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Defs-versions.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Defs-windows.gmk' (search path) (no ~ expansion)... jdk/make/common/shared/Defs.gmk:563: *** ERROR: Trouble with the absolute path for OUTPUTDIR './bui ld/windows-i586'. Stop. FrancisANDRE@idefix /cygdrive/Z/JDK/hsx/jdk7u $ env | grep ALT ALT_SLASH_JAVA=C:/Progra~1/Java/jdk1.7.0_45 ALT_FREETYPE_HEADERS_PATH=Z:/JDK/freetype-2.4.7/include ALT_JDK_IMPORT_PATH=C:/Progra~1/Java/jdk1.7.0_45 ALT_FREETYPE_LIB_PATH=Z:/JDK/freetype-2.4.7/objs/win32/vc2010 ALT_DXSDK_PATH=C:/PROGRA~1/MI7482~1 ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_45
Help: jdk/make/common/shared/Defs.gmk:563: *** ERROR: Trouble with the absolute path for OUTPUTDIR '
Hi Using a fresh copy of the jdk7u repository, and running make -d sanity, I got the error below. Why OUTPUTDIR must be absolute or if it must be absolute, why it is not when running make sanity? It seems to me that OUTPUTDIR is computed in the jdk subdirectory makefiles while it is not in the top level Makefile. Thus, the check that it must be absolute in the included jdk/make/common/shared/Defs.gmk fails. The only way I found to bypass this error is to set ALT_OUTPUTDIR=Z:/JDK/hsx/jdk7u/build/windows-i586 Francis FrancisANDRE@idefix /cygdrive/Z/JDK/hsx/jdk7u $ make -d sanity GNU Make 3.82 Built for i686-pc-cygwin Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading makefiles... Reading makefile `Makefile'... Reading makefile `jdk/make/common/shared/Defs-control.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Platform.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Defs.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Defs-utils.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Defs-versions.gmk' (search path) (no ~ expansion)... Reading makefile `jdk/make/common/shared/Defs-windows.gmk' (search path) (no ~ expansion)... jdk/make/common/shared/Defs.gmk:563: *** ERROR: Trouble with the absolute path for OUTPUTDIR './bui ld/windows-i586'. Stop. FrancisANDRE@idefix /cygdrive/Z/JDK/hsx/jdk7u $ env | grep ALT ALT_SLASH_JAVA=C:/Progra~1/Java/jdk1.7.0_45 ALT_FREETYPE_HEADERS_PATH=Z:/JDK/freetype-2.4.7/include ALT_JDK_IMPORT_PATH=C:/Progra~1/Java/jdk1.7.0_45 ALT_FREETYPE_LIB_PATH=Z:/JDK/freetype-2.4.7/objs/win32/vc2010 ALT_DXSDK_PATH=C:/PROGRA~1/MI7482~1 ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_45
[7u] WXP/Cygwin/VS2010 patch to remove invali option from the SA compilation
Hi Following is a patch to avoid warning messages produced by the VS2010 compiler when compiling SA as cl: Ligne de commande warning D9035: l'option 'GZ' est deconseille et sera supprime dans une version ulterieure cl: Ligne de commande warning D9036: utilisez 'RTC1' … la place de 'GZ' cl: Ligne de commande warning D9035: l'option 'o' est deconseille et sera supprime dans une version ultrieure cl: Ligne de commande warning D9002: option '-YX' inconnue ignoree here the patch --- diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make --- a/make/windows/makefiles/sa.make +++ b/make/windows/makefiles/sa.make @@ -94,7 +94,7 @@ SA_LD_FLAGS = bufferoverflowU.lib !endif !else -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D WIN32 -D _WINDOWS -D _DEB UG -D _CONSOLE -D _MBCS -YX -FD -GZ -c +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D WIN32 -D _WINDOWS -D _DEB UG -D _CONSOLE -D _MBCS -FD -RTC1 -c !if $(ENABLE_FULL_DEBUG_SYMBOLS) == 1 SA_CFLAGS = $(SA_CFLAGS) -ZI !endif Francis
[7u]: ERROR: Trouble with the absolute path for OUTPUTDIR './bui, ld/windows-i586'. Stop.
Hi Just cloning this repository http://hg.openjdk.java.net/jdk7u/jdk7u to a fresh new directory on a WXP/Cygwin platform with the following ALT_* variables $ env | grep ALT ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_40 ALT_SLASH_JAVA=C:/Progra~1/Java/jdk1.7.0_40 ALT_JDK_IMPORT_PATH=C:/Progra~1/Java/jdk1.7.0_40 ALT_FREETYPE_HEADERS_PATH=C:/Cygwin/OpenJDK/freetype-2.4.7/include ALT_FREETYPE_LIB_PATH=C:/Cygwin/OpenJDK/freetype-2.4.7/objs/win32/vc2010 ALT_DXSDK_PATH=C:/PROGRA~1/MI7482~1 FREETYPE2_LIB_PATH=C:/Cygwin/OpenJDK/freetype-2.4.7/objs/win32/vc2010 FrancisANDRE@idefix /cygdrive/Z/JDK/jdk7u $ make sanity jdk/make/common/shared/Defs.gmk:559: *** ERROR: Trouble with the absolute path for OUTPUTDIR './bui ld/windows-i586'. Stop. My understanding is that there is no need to specify the ALT_OUTPUTDIR but it seems to be needed by make sanity. Did I miss something? Francis
Re: RFR (S): JDK-8025933 Configure should support French cl.exe
Le 07/10/2013 11:32, Magnus Ihse Bursie a écrit : On 2013-10-06 05:19, David Holmes wrote: Magnus, Echoing Naoto's comments I don't agree that we should be supporting this. In the original email a workaround was mentioned using an environment variable - if that is the case then I don't think we need to do anything here. Even if not, who knows how many other languages we might have to support in this way. I didn't think a simple patch would generate so much discussion. :-) I'm just about this close --| |-- to dropping this but let me just elaborate on a few points here: 1) The fix was indeed intended to be language independet; the comment about Frech was unfortunate and should be rewritten. 2) The workaround mentioned was for JDK7. No such workaround is possible for JDK8, and we will fail at configure time. 3) I think English should be the supported locale; unfortunately on Windows platforms changing locale is system-wide and thus not possible to change for only JDK build tools. Building in a virtual machine with English locale to work around this is of course possible, but that will make a slow build even slower. 4) At the very least, a simple fix that don't get configure artificially caught when trying to check if the tools is okay, when it actually is, would be okay. New webrev fixing the comment: http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.02 If anyone still objects to this, let me known and I'll drop it. You must change in your patch the ' ' character following ersion by a dot '.' because in fact the character is X'FF' which is not displayable and replaced by a space. h: 43 6F 6D 70 69 6C 61 74 65 75 72 20 64 27 6F 70 ; Compilateur d'op 0010h: 74 69 6D 69 73 61 74 69 6F 6E 20 4D 69 63 72 6F ; timisation Micro 0020h: 73 6F 66 74 20 28 52 29 20 33 32 FF 62 69 74 73 ; soft (R) 32ÿbits 0030h: 20 43 2F 43 2B 2B 20 76 65 72 73 69 6F 6E FF 31 ; C/C++ versionÿ1 0040h: 36 2E 30 30 2E 33 30 33 31 39 2E 30 31 20 70 6F ; 6.00.30319.01 po 0050h: 75 72 20 38 30 78 38 36 0A ; ur 80x86. By the way, I would prefer a fix like in the hotspot JDK7u with a user settable variable like ALT_MSVC_COMPILER_VERSION and ALT_MSVC_LINK_VERSION. If those variables are not defined, then use the make script. There are so many ALT_ variables to customize the build that it make sense to use ALT variables also in that case. But you decide, it is just my pratical preference. Francis /Magnus
RFR: Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop
Hi I submit this patch for review for this Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop The webrev.ksh is broken on WXP/Cygwin. So I am providing here the hg outgoing report as well as the new file README-Windows-Cygwin-VS2010 Francis $ hg outgoing -v comparing with http://hg.openjdk.java.net/jdk7u/jdk7u40-dev searching for changes changeset: 723:ca9d79ba85a6 tag: tip user:fandre francis.andre.kampb...@orange.fr date:Sun Oct 06 19:11:23 2013 +0100 files: README-Windows-Cygwin-VS2010 description: Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop The multiple target patterns error is coming from the version of GNU make.exe in the Cygwin distribu tion that does not recognize drive letter in path. The solution is to fully explained in a blog of Volker SIMONIS which is printed in this new file. *N o one* will succeed to build the OpenJDK on windows with cygwin and VS2010 without following the Volker's paper. That's why IMO, it is mandatory to join this README-Windows-Cygwin-VS2010 in the distribution. YAOJOWBI - Yet another OpenJDK on Windows Build Instruction By simonis Created 2011-10-28 11:00 Posted by simonis [1] on October 28, 2011 at 11:00 AM PDT Printed from https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction?force=510 This blog describes how to build both, a 64-bit and a 32-bit version of OpenJDK 8 on a plain, vanilla WindowsXP 64-bit operating system using only free (as in free beer) tools. Contents Getting started VisualC++ Express Windows SDK DirectX SDK TortoiseHg Java 7 JDK Ant Cygwin GNU make FreeType PATH handling OpenJDK sources JAXP and JAX_WS msvcr100.dll Building There are several tutorials out there which explain in more or less detail how to build OpenJDK on Windows. The problem with most of them is that they are either outdated (will happen with this blog as well:) or they use compilers which either aren't available anymore or which are not free. This blog will describe how to build both, a 64-bit and a 32-bit version of OpenJDK 8 on a plain, vanilla WindowsXP 64-bit operating system using only free (as in free beer) tools. Unfortunately, building OpenJDK on Windows is still far away from being straightforward as can be seen from the regular desperate help requests on the OpenJDK mailing lists. This has many reasons and I neither want to discuss them nor do I want to blame anybody for this fact. Instead I hope this post can help to improve the OpenJDK build documentation [2] and perhaps even the build process itself. Getting started As stated above, I started with a fresh, 64-bit WindowsXP installation. In fact I used a VmWare-Image in Oracle VirtualBox 4.1.4 on 64-bit Ubuntu 10.04 and in the VmWare Player 3.1.4 on 64-bit Windows 7. The first step was to install the free Microsoft C/C++ compilers and various dependencies required by OpenJDK. If not mentioned otherwise, I've installed all the packages mentioned here in the default location that was suggested by the respective installers. VisualC++ 2010 Express Download and install the free VisualC++ 2010 Express compilers from: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express [3]. Notice that this will require the installation of the Windows Imaging Component (64-bit) which is not present in a clean XP installation, but the VisualC++ installer will point you to the right URL from where you can get it (just for any case, here's where I finally downloaded it from: http://www.microsoft.com/download/en/details.aspx?displaylang=enid=1385 [4]). Windows SDK for Windows 7 and .Net Unfortunately, the VisualC++ 2010 Express package only contains 32-bit compilers. So if we want to build a 64-bit JVM we have to additionally install the Windows SDK for Windows 7 and .Net from http://www.microsoft.com/download/en/details.aspx?id=8279 [5]. (Notice that the Windows SDK now also contains the Itanium cross compiler. So should there be a native IA64 port in the OpenJDK anytime soon, it will be possible to build it with this setup as well:) Microsoft DirectX 9.0 SDK Another build requirement is the Microsoft DirectX 9.0 SDK header files and libraries. It can be easily installed from http://www.microsoft.com/download/en/details.aspx?displaylang=enid=21416 [6] but be sure to check the corresponding Microsoft DirectX [7] section in the OpenJDK Readme [2] in the case the required version changed. TortoiseHg To get the OpenJDK source code, we need a Mercurial [8] client. TortoiseHg [9] is an easy to install Mercurial distribution for Windows which can be downloaded from http://tortoisehg.bitbucket.org/download [10]. The installation step will updated the system path automatically.
7u40 on WXP/Cygwin: webrev: Is there a java or ant version of webrev?
Hi Builders I am really fighting against the triumvira (Cygwin, ksh, webrev.ksh) because of a bug in the cd command of the korn shell under cygwin -- log below --. The cd command prepends the target directory where to go by the current $PWD. cd Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles becomes cd /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles and for sure, the translated directory does not exist. So, it is clear that's not a problem with webrev.ksh but I am stacked with and I have no idea when this problem will be fixed in the Cygwin tool. Thus I am wondering if there is a java or ant version of webrev because I am not able to fix this issue in a 3000+ lines of ksh while that's not a problem in java or ant. Francis $ ksh ./make/scripts/webrev.ksh -v ./make/scripts/webrev.ksh version: 23.18-hg+jbs SCM detected: mercurial Workspace: Z:/DEV/OpenJDK_7u40/hotspot Compare against: http://hg.openjdk.java.net/jdk7u/jdk7u40-dev/hotspot Output to: Z:/DEV/OpenJDK_7u40/hotspot/webrev Output Files: ./make/scripts/webrev.ksh[2899]: cd: /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles: No such file or directory abort: cannot follow file not in parent revision: sa.make make/windows/makefiles/sa.make ./make/scripts/webrev.ksh[2899]: cd: /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles: No such file or directory *** Error: file not in parent or child
Re: RFR (S): JDK-8025933 Configure should support French cl.exe
Changing the LANG to C or en_US does not work neither. The VS C++ compiler does not use the LANG variable for providing messages. I know that on WXP, there are options to setup the language of work like English but I cannot turn my PC to English because others tools like Excel will work in English with the decimal point as '.' instead of the ',' for France... The setup of the language for WS Studio is just the one you choose at download time -- much like the JDK of Sun for Japanese or Chinese --; The point here is that I succeed in downloading the ENU VS2010 version but after the installation, it is the French version that runs Anyhow, I think that for this specific case of VS C++ which is not a compiler that follows the Linux/Cygwin rules --ie LANG=en_US, one should provide a way to support non en_US VS C++ compiler for computing the vervion used. Francis Le 04/10/2013 19:16, Naoto Sato a écrit : The issue here (and the reason why the rule is to run build in en_US) is that the build would be error prone if we allow running builds in locales other than US English. In the past, we had several build errors related to this, e.g., 'date' command produced differently formatted date string for each locale which resulted in build errors. Naoto On 10/4/13 9:42 AM, Magnus Ihse Bursie wrote: I agree that the general rule is to build in an English environment. Unfortunately, on Windows, it is not as trivial, nor often possible to get tools to produce different output by setting a locale. It is not the case with cl.exe, anyway. And in this case, Microsoft apparently does not provide the English version to French users. Hence this fix. /Magnus 4 okt 2013 kl. 18:18 skrev Naoto Sato naoto.s...@oracle.com: Hi Magnus, Well, it would work for Latin languages, but not for others, e.g., CJK. I thought that the general rule was to run the build in English environment. I would think that French CL.EXE would produce English version string on Windows configured for en_US locale. Naoto On 10/4/13 6:12 AM, Magnus Ihse Bursie wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8025933 In France, it's not possible to download the English version of Visual Studio; hence CL.EXE presents itself as: Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version 16.00.30319.01 pour 80x86 instead of Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86 With a simple fix we can handle this in configure as well. WebRev: http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01 /Magnus
JDK7u40: webrev does not seem to work properly on WXP/Cygwin
Hi I am trying to build a webrev for an outgoing patch on a WXP/x86/Cygwin platform, but it seems that the webrev script is not handling properly the /cygdrive/ path. So, I am wondering if there a specific configuration guide for using this script under cygwin? Francis FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK_7u40/hotspot $ ksh ./make/scripts/webrev.ksh make/windows/makefiles/sa.make SCM detected: mercurial File list from: make/windows/makefiles/sa.make Workspace: Z:/DEV/OpenJDK_7u40/hotspot Compare against: http://hg.openjdk.java.net/jdk7u/jdk7u40-dev/hotspot Output to: Z:/DEV/OpenJDK_7u40/hotspot/webrev Output Files: ./make/scripts/webrev.ksh[2895]: cd: /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspo t: No such file or directory abort: cannot follow file not in parent revision: checkAndBuildSA:: checkAndBuildSA:: ./make/scripts/webrev.ksh[2895]: cd: /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/Ope nJDK_7u40/hotspot: No such file or directory *** Error: file not in parent or child
JDK7u40: build issue with a french VS2010 Express
Hi
In the 7u40/jdk/make/common/shared/Compiler-msvc.gmk, the code for computing the
CC_VER does work with a French VS2010 Express compiler
CC_VER := $(shell $(CC) 21 | $(HEAD) -n 1 | $(SED) 's/.*\(Version.*\)/\1/' |
$(NAWK) '{print $$2}')
because the cl command returns
Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version 16.00.30319.01
pour 80x86
Copyright (C) Microsoft Corporation. Tous droits réservés.
utilisation : cl [ option... ] nom de fichier... [ /link linkoption... ]
So, soneone from the build team would say: Hey guy, pick up the English version
and it will work!. But that does not work neither because when one download
VS2010 Express from a French territory, one gets the French version EVEN if the
English version was explicitly requested (I made it twice, thinking I missed to
select the English version).
The problem has already been solved in the hotspot build by using the externals
variables FORCE_MSC_VER and FORCE_LINK_VERSION in this file
/hotspot/make/windows/get_msc_ver.sh
I can build a fix for this issue but I think it is better than someone from the
build team fix this issue because of the overall responsibility of making the
build correct on the WXP/VS2010 as well as others platforms which I do not have.
Francis
Re: JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot
Sean The point is that OpenJDK7u is not open source while OpenJDK7 is... Following is a snippet of the make log joined... That's the same story for the HSX project. Thus either the OpenJDK7u is an open source project and then the makefiles are wrong, either it is not and then I need the backport on the OpenJDK7 project. Regards Francis mv ad_x86_32.cpp ad_x86_32.hpp ad_x86_32_clone.cpp ad_x86_32_expand.cpp ad_x86_32_forma t.cpp ad_x86_32_gen.cpp ad_x86_32_misc.cpp ad_x86_32_peephole.cpp ad_x86_32_pipeline.cpp adGlob als_x86_32.hpp dfa_x86_32.cpp adfiles/ C:\Progra~1\Java\jdk1.6.0_35\bin\javac -g -encoding ascii -source 6 -target 6 -d jvmtifile s Z:\DEV\OpenJDK7u\hotspot/src/share/vm/prims/jvmtiGen.java Generating jvmtifiles/jvmtiEnv.hpp Generating jvmtifiles/jvmtiEnter.cpp Generating jvmtifiles/jvmtiEnterTrace.cpp Generating jvmtifiles/jvmtiEnvRecommended.cpp Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp Generating jvmtifiles/jvmti.h *NMAKE : fatal error U1073: incapable d'obtenir 'Z:\DEV\OpenJDK7u\hotspot/src/closed/share/vm/trace/t** **raceEventClasses.xsl'* Stop. NMAKE : fatal error U1077: 'cd' : code retour '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE' : code retour '0x2' Stop. Makefile:191: recipe for target `generic_build2' failed make[1]: *** [generic_build2] Error 2 make[1] : on quitte le répertoire « /cygdrive/z/DEV/OpenJDK7u/hotspot/make » Makefile:151: recipe for target `jvmg' failed make: *** [jvmg] Error 2 FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK7u/hotspot/make Le 22/09/2013 20:40, Seán Coffey a écrit : Francis, the OpenJDK 7 repository corresponds to the JDK 7 GA release made a few years ago. The OpenJDK 7u repository is used to gather fixes for the JDK 7 update releases. Isn't this patch already in the updates ? (7u2) http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2f27ed2a98fa https://bugs.openjdk.java.net/browse/JDK-2213981 regards, Sean. On 22/09/2013 09:37, Francis ANDRE wrote: HI the patch JDK-7082220 : Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls is missing in the OpenJDK7/hotspot/src/share/tools/ProjectCreator/WinGammaPlatformVC10.java. I applied it localy but some other OpenJDK developpers on WXP/VS2010 would benefit of this patch if it was applied to the OpenJDK7 forest. So I am wondering how to request a backport of this patch to the OpenJDK7/hotspot repository? Regards FA cd /cygdrive/z/DEV/OpenJDK7u/hotspot/make; \ make BUILD_FLAVOR=jvmg VM_TARGET=jvmg generic_build2 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 make[1] : on entre dans le répertoire « /cygdrive/z/DEV/OpenJDK7u/hotspot/make » mkdir -p /cygdrive/z/DEV/OpenJDK7u/hotspot/build/windows cd /cygdrive/z/DEV/OpenJDK7u/hotspot/build/windows; \ MAKEFLAGS= MFLAGS= EXTRA_CFLAGS= nmake -NOLOGO -f Z:/DEV/OpenJDK7u/hotspot/make/windows/build.make \ Variant=compiler2 \ WorkSpace=Z:\\DEV\\OpenJDK7u\\hotspot \ BootStrapDir=C:\\Progra~1\\Java\\jdk1.6.0_35 \ BuildUser=FrancisANDRE \ ARCH=x86 BUILDARCH=i486 Platform_arch=x86 Platform_arch_model=x86_32 ENABLE_FULL_DEBUG_SYMBOLS=1 ZIP_DEBUGINFO_FILES=1 RM=rm -f ZIPEXE=zip JDK_MKTG_VERSION=7.0 JDK_MAJOR_VER=1 JDK_MINOR_VER=7 JDK_MICRO_VER=0 BUILD_WIN_SA=1 JAVA_HOME=C:\\Progra~1\\Java\\jdk1.6.0_35 OUTPUTDIR=Z:\\DEV\\OpenJDK7u\\hotspot\\build\\windows GAMMADIR=Z:\\DEV\\OpenJDK7u\\hotspot MAKE_VERBOSE=y HOTSPOT_RELEASE_VERSION=24.0-b56 JRE_RELEASE_VERSION=1.7.0 HOTSPOT_BUILD_VERSION=internal INCLUDE_TRACE=1 jvmg cd windows_i486_compiler2 nmake -nologo -f Z:\DEV\OpenJDK7u\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=debug ARCH=x86 nmake in ./generated cd generated C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE -NOLOGO -f Z:\DEV\OpenJDK7u\hotspot\make\windows\makefiles\generated.make DIR=.\generated BUILD_FLAVOR=debug NMAKE : fatal error U1073: incapable d'obtenir 'Z:\DEV\OpenJDK7u\hotspot/src/closed/share/vm/trace/traceEventClasses.xsl' Stop. NMAKE : fatal error U1077: 'cd' : code retour '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE' : code retour '0x2' Stop. Makefile:191: recipe for target `generic_build2' failed make[1]: *** [generic_build2] Error 2 make[1] : on quitte le répertoire « /cygdrive/z/DEV/OpenJDK7u/hotspot/make » Makefile:151: recipe for target `jvmg' failed make: *** [jvmg] Error 2
Re: JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot
Le 23/09/2013 18:54, Erik Joelsson a écrit : It's certainly not supposed to fail like that. I'm not able to reproduce this problem cloning from http://hg.openjdk.java.net/jdk7u/jdk7u-dev. From where did you get your sources? From http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot with hg clone http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot the Source Code Mercurial 7u (on the left panel) links to this repository:http://hg.openjdk.java.net/jdk7u/jdk7u. So, I take it as the repository base for getting hotspot. /Erik On 2013-09-23 17:51, Francis ANDRE wrote: Sean The point is that OpenJDK7u is not open source while OpenJDK7 is... Following is a snippet of the make log joined... That's the same story for the HSX project. Thus either the OpenJDK7u is an open source project and then the makefiles are wrong, either it is not and then I need the backport on the OpenJDK7 project. Regards Francis mv ad_x86_32.cpp ad_x86_32.hpp ad_x86_32_clone.cpp ad_x86_32_expand.cpp ad_x86_32_forma t.cpp ad_x86_32_gen.cpp ad_x86_32_misc.cpp ad_x86_32_peephole.cpp ad_x86_32_pipeline.cpp adGlob als_x86_32.hpp dfa_x86_32.cpp adfiles/ C:\Progra~1\Java\jdk1.6.0_35\bin\javac -g -encoding ascii -source 6 -target 6 -d jvmtifile s Z:\DEV\OpenJDK7u\hotspot/src/share/vm/prims/jvmtiGen.java Generating jvmtifiles/jvmtiEnv.hpp Generating jvmtifiles/jvmtiEnter.cpp Generating jvmtifiles/jvmtiEnterTrace.cpp Generating jvmtifiles/jvmtiEnvRecommended.cpp Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp Generating jvmtifiles/jvmti.h *NMAKE : fatal error U1073: incapable d'obtenir 'Z:\DEV\OpenJDK7u\hotspot/src/closed/share/vm/trace/t** **raceEventClasses.xsl'* Stop. NMAKE : fatal error U1077: 'cd' : code retour '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE' : code retour '0x2' Stop. Makefile:191: recipe for target `generic_build2' failed make[1]: *** [generic_build2] Error 2 make[1] : on quitte le répertoire « /cygdrive/z/DEV/OpenJDK7u/hotspot/make » Makefile:151: recipe for target `jvmg' failed make: *** [jvmg] Error 2 FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK7u/hotspot/make Le 22/09/2013 20:40, Seán Coffey a écrit : Francis, the OpenJDK 7 repository corresponds to the JDK 7 GA release made a few years ago. The OpenJDK 7u repository is used to gather fixes for the JDK 7 update releases. Isn't this patch already in the updates ? (7u2) http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2f27ed2a98fa https://bugs.openjdk.java.net/browse/JDK-2213981 regards, Sean. On 22/09/2013 09:37, Francis ANDRE wrote: HI the patch JDK-7082220 : Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls is missing in the OpenJDK7/hotspot/src/share/tools/ProjectCreator/WinGammaPlatformVC10.java. I applied it localy but some other OpenJDK developpers on WXP/VS2010 would benefit of this patch if it was applied to the OpenJDK7 forest. So I am wondering how to request a backport of this patch to the OpenJDK7/hotspot repository? Regards FA
Re: JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot
Erik I got the same error with this repository: hg clone http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot $ pwd /cygdrive/z/DEV/OpenJDK7u hg clone http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot cd hotspot/make make all_debug ... Generating jvmtifiles/jvmtiEnter.cpp Generating jvmtifiles/jvmtiEnterTrace.cpp Generating jvmtifiles/jvmtiEnvRecommended.cpp Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp Generating jvmtifiles/jvmti.h NMAKE : fatal error U1073: incapable d'obtenir 'Z:\DEV\OpenJDK7u\hotspot/src/closed/share/vm/trace/t raceEventClasses.xsl' Stop. NMAKE : fatal error U1077: 'cd' : code retour '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE' : code retour '0x2' Stop. Makefile:191: recipe for target `generic_build2' failed make[1]: *** [generic_build2] Error 2 make[1] : on quitte le répertoire « /cygdrive/z/DEV/OpenJDK7u/hotspot/make » Makefile:151: recipe for target `jvmg' failed make: *** [jvmg] Error 2 Le 23/09/2013 18:54, Erik Joelsson a écrit : It's certainly not supposed to fail like that. I'm not able to reproduce this problem cloning from http://hg.openjdk.java.net/jdk7u/jdk7u-dev. From where did you get your sources? /Erik On 2013-09-23 17:51, Francis ANDRE wrote: Sean The point is that OpenJDK7u is not open source while OpenJDK7 is... Following is a snippet of the make log joined... That's the same story for the HSX project. Thus either the OpenJDK7u is an open source project and then the makefiles are wrong, either it is not and then I need the backport on the OpenJDK7 project. Regards Francis mv ad_x86_32.cpp ad_x86_32.hpp ad_x86_32_clone.cpp ad_x86_32_expand.cpp ad_x86_32_forma t.cpp ad_x86_32_gen.cpp ad_x86_32_misc.cpp ad_x86_32_peephole.cpp ad_x86_32_pipeline.cpp adGlob als_x86_32.hpp dfa_x86_32.cpp adfiles/ C:\Progra~1\Java\jdk1.6.0_35\bin\javac -g -encoding ascii -source 6 -target 6 -d jvmtifile s Z:\DEV\OpenJDK7u\hotspot/src/share/vm/prims/jvmtiGen.java Generating jvmtifiles/jvmtiEnv.hpp Generating jvmtifiles/jvmtiEnter.cpp Generating jvmtifiles/jvmtiEnterTrace.cpp Generating jvmtifiles/jvmtiEnvRecommended.cpp Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp Generating jvmtifiles/jvmti.h *NMAKE : fatal error U1073: incapable d'obtenir 'Z:\DEV\OpenJDK7u\hotspot/src/closed/share/vm/trace/t** **raceEventClasses.xsl'* Stop. NMAKE : fatal error U1077: 'cd' : code retour '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE' : code retour '0x2' Stop. Makefile:191: recipe for target `generic_build2' failed make[1]: *** [generic_build2] Error 2 make[1] : on quitte le répertoire « /cygdrive/z/DEV/OpenJDK7u/hotspot/make » Makefile:151: recipe for target `jvmg' failed make: *** [jvmg] Error 2 FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK7u/hotspot/make Le 22/09/2013 20:40, Seán Coffey a écrit : Francis, the OpenJDK 7 repository corresponds to the JDK 7 GA release made a few years ago. The OpenJDK 7u repository is used to gather fixes for the JDK 7 update releases. Isn't this patch already in the updates ? (7u2) http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2f27ed2a98fa https://bugs.openjdk.java.net/browse/JDK-2213981 regards, Sean. On 22/09/2013 09:37, Francis ANDRE wrote: HI the patch JDK-7082220 : Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls is missing in the OpenJDK7/hotspot/src/share/tools/ProjectCreator/WinGammaPlatformVC10.java. I applied it localy but some other OpenJDK developpers on WXP/VS2010 would benefit of this patch if it was applied to the OpenJDK7 forest. So I am wondering how to request a backport of this patch to the OpenJDK7/hotspot repository? Regards FA
Re: [SPAM]Re: JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot
:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\Pro gram Files\Microsoft Visual Studio 10.0\VC\LIB LOGONSERVER=\\IDEFIX MANPATH=/usr/local/man:/usr/share/man:/usr/man: MAVEN_HOME=C:\Program Files\Apache Software Foundation\apache-maven-3.0.3 MAVEN_OPTS=-XX:MaxPermSize=128m -Xmx1024m MQ_FILE_PATH=C:\Program Files\IBM\WebSphere MQ MQ_JAVA_DATA_PATH=C:\Program Files\IBM\WebSphere MQ MQ_JAVA_INSTALL_PATH=C:\Program Files\IBM\WebSphere MQ\Java MQ_JAVA_LIB_PATH=C:\Program Files\IBM\WebSphere MQ\Java\lib MQ_JRE_PATH=C:\Program Files\IBM\WebSphere MQ\java\jre MQFT_JAVA_LIB_PATH=C:\Program Files\IBM\WebSphere MQ\java\jre\lib MQFT_JRE_BIN_PATH=C:\Program Files\IBM\WebSphere MQ\java\jre\bin NUMBER_OF_PROCESSORS=4 OLDPWD=/cygdrive/z/DEV/OpenJDK7u OpenJDK=Z:\DEV\OpenJDK7 OS=Windows_NT PATH=%JAVA_HOME%/bin:/cygdrive/c/Program Files/IBM/WebSphere MQ/Java/lib:/cygdrive/c/PVSW/Bin:/cygdr ive/c/Program Files/IBM/CICS Transaction Gateway/bin:/cygdrive/c/zOS/Hercules/bin:/cygdrive/z/isode- 8.0/com.pac.osi.cpp/bin:/cygdrive/z/DEV/3rd/poco/bin:/cygdrive/c/Program Files/Perl/bin:/cygdrive/c/ WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/Hum mingbird/Connectivity/7.00/Accessories:/cygdrive/c/Program Files/doxygen/bin:/cygdrive/c/PROGRA~1/AT T/Graphviz/bin:/cygdrive/c/Program Files/IDM Computer Solutions/UltraEdit-32:/cygdrive/c/PROGRA~1/IB M/SQLLIB/BIN:/cygdrive/c/PROGRA~1/IBM/SQLLIB/FUNCTION:/cygdrive/c/PROGRA~1/IBM/SQLLIB/SAMPLES/REPL:/ cygdrive/c/Program Files/IBM/Installation Manager/eclipse/lib:/cygdrive/c/Program Files/Subversion/b in:/cygdrive/c/Program Files/Graphviz/Bin:/cygdrive/c/Program Files/Fichiers communs/DivX Shared:/cy gdrive/c/Program Files/IBM/WebSphere MQ/bin:/cygdrive/c/Program Files/IBM/WebSphere MQ/tools/c/sampl es/bin:/cygdrive/c/Program Files/Mercurial:/cygdrive/c/Program Files/TortoiseSVN/bin:/cygdrive/c/Pro gram Files/Fichiers communs/Acronis/SnapAPI:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0:/cyg drive/c/Program Files/Microsoft SQL Server/100/Tools/Binn:/cygdrive/c/Program Files/Microsoft SQL Se rver/100/DTS/Binn:/cygdrive/c/Program Files/scala/bin:/cygdrive/c/Program Files/QuickTime/QTSystem:/ cygdrive/c/Program Files/Mercurial:/cygdrive/c/Program Files/TortoiseHg:/cygdrive/c/Program Files/Mi crosoft Visual Studio 10.0/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 10.0/VC/BIN :/cygdrive/c/Program Files/Microsoft Visual Studio 10.0/Common7/Tools:/cygdrive/c/WINDOWS/Microsoft. NET/Framework/v4.0.30319:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5:/cygdrive/c/Program Files/ Microsoft Visual Studio 10.0/VC/VCPackages:/cygdrive/c/Program Files/HTML Help Workshop:/cygdrive/c/ Program Files/Microsoft SDKs/Windows/v7.0A/bin/NETFX 4.0 Tools:/cygdrive/c/Program Files/Microsoft S DKs/Windows/v7.0A/bin:/cygdrive/c/mingw/bin:/cygdrive/c/Program Files/Apache Software Foundation/apa che-ant-1.8.4/bin:/cygdrive/c/Program Files/Apache Software Foundation/apache-maven-3.0.3/bin:/cygdr ive/c/Program Files/PostgresPlus/8.4SS/bin:/usr/local/bin:/usr/bin PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1 POCO_BASE=Z:\DEV\3rd\poco PRINTER=Dell Photo AIO Printer 962 PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 6 Model 30 Stepping 5, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=1e05 PROGRAMFILES=C:\Program Files PROMPT=$P$G PS1=\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ PWD=/cygdrive/z/DEV/OpenJDK7u/hotspot/make QTJAVA=C:\Program Files\Java\jre6\lib\ext\QTJava.zip SESSIONNAME=Console SHELL=/bin/bash SHLVL=1 SOURCE_CODE=/cygdrive/z/DEV/OpenJDK7 SYSTEMDRIVE=C: SYSTEMROOT=C:\WINDOWS TEMP=/tmp temp=C:\DOCUME~1\FRANCI~1\LOCALS~1\Temp TERM=cygwin TMP=/tmp tmp=C:\DOCUME~1\FRANCI~1\LOCALS~1\Temp TZ=Europe/Paris USER=FrancisANDRE USERDOMAIN=IDEFIX USERNAME=FrancisANDRE USERPROFILE=C:\Documents and Settings\FrancisANDRE VS100COMNTOOLS=C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\ VS71COMNTOOLS=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\ WINDIR=C:\WINDOWS XCALIA_CORE_HOME=C:\XCalia\5.2.0 Le 23/09/2013 19:46, Seán Coffey a écrit : I don't see the failure either. Ran an OpenJDK test job through JPRT. I wonder if make version and/or shell env could have an impact ? Can you share more details Francis ? I see an OPENJDK condition expression in trace.make and wonder if that's being parsed incorrectly for this issue ? http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/file/tip/make/windows/makefiles/trace.make regards, Sean. On 23/09/13 17:54, Erik Joelsson wrote: It's certainly not supposed to fail like that. I'm not able to reproduce this problem cloning from http://hg.openjdk.java.net/jdk7u/jdk7u-dev. From where did you get your sources? /Erik On 2013-09-23 17:51, Francis ANDRE wrote: Sean The point is that OpenJDK7u is not open source while OpenJDK7 is... Following is a snippet of the make log joined... That's the same story for the HSX project. Thus
Re: [SPAM]Re: JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot
Sean OK, I found the problem: I had in the Windows environement variables a variable named OpenJDK, which under nmake/make gets translated into OPENJDK under cygwin, but echo $OpenJDK prints the value while echo $OPENJDK prints nothing! Sorry for the noise and thanks for your attention on my problem May be it would be interesting to add a check on the value of OPENJDK somewhere to avoid such mistake. Francis Le 23/09/2013 19:46, Seán Coffey a écrit : I don't see the failure either. Ran an OpenJDK test job through JPRT. I wonder if make version and/or shell env could have an impact ? Can you share more details Francis ? I see an OPENJDK condition expression in trace.make and wonder if that's being parsed incorrectly for this issue ? http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/file/tip/make/windows/makefiles/trace.make regards, Sean. On 23/09/13 17:54, Erik Joelsson wrote: It's certainly not supposed to fail like that. I'm not able to reproduce this problem cloning from http://hg.openjdk.java.net/jdk7u/jdk7u-dev. From where did you get your sources? /Erik On 2013-09-23 17:51, Francis ANDRE wrote: Sean The point is that OpenJDK7u is not open source while OpenJDK7 is... Following is a snippet of the make log joined... That's the same story for the HSX project. Thus either the OpenJDK7u is an open source project and then the makefiles are wrong, either it is not and then I need the backport on the OpenJDK7 project. Regards Francis mv ad_x86_32.cpp ad_x86_32.hpp ad_x86_32_clone.cpp ad_x86_32_expand.cpp ad_x86_32_forma t.cpp ad_x86_32_gen.cpp ad_x86_32_misc.cpp ad_x86_32_peephole.cpp ad_x86_32_pipeline.cpp adGlob als_x86_32.hpp dfa_x86_32.cpp adfiles/ C:\Progra~1\Java\jdk1.6.0_35\bin\javac -g -encoding ascii -source 6 -target 6 -d jvmtifile s Z:\DEV\OpenJDK7u\hotspot/src/share/vm/prims/jvmtiGen.java Generating jvmtifiles/jvmtiEnv.hpp Generating jvmtifiles/jvmtiEnter.cpp Generating jvmtifiles/jvmtiEnterTrace.cpp Generating jvmtifiles/jvmtiEnvRecommended.cpp Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp Generating jvmtifiles/jvmti.h *NMAKE : fatal error U1073: incapable d'obtenir 'Z:\DEV\OpenJDK7u\hotspot/src/closed/share/vm/trace/t** **raceEventClasses.xsl'* Stop. NMAKE : fatal error U1077: 'cd' : code retour '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE' : code retour '0x2' Stop. Makefile:191: recipe for target `generic_build2' failed make[1]: *** [generic_build2] Error 2 make[1] : on quitte le répertoire « /cygdrive/z/DEV/OpenJDK7u/hotspot/make » Makefile:151: recipe for target `jvmg' failed make: *** [jvmg] Error 2 FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK7u/hotspot/make Le 22/09/2013 20:40, Seán Coffey a écrit : Francis, the OpenJDK 7 repository corresponds to the JDK 7 GA release made a few years ago. The OpenJDK 7u repository is used to gather fixes for the JDK 7 update releases. Isn't this patch already in the updates ? (7u2) http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2f27ed2a98fa https://bugs.openjdk.java.net/browse/JDK-2213981 regards, Sean. On 22/09/2013 09:37, Francis ANDRE wrote: HI the patch JDK-7082220 : Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls is missing in the OpenJDK7/hotspot/src/share/tools/ProjectCreator/WinGammaPlatformVC10.java. I applied it localy but some other OpenJDK developpers on WXP/VS2010 would benefit of this patch if it was applied to the OpenJDK7 forest. So I am wondering how to request a backport of this patch to the OpenJDK7/hotspot repository? Regards FA
JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot
HI the patch JDK-7082220 : Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls is missing in the OpenJDK7/hotspot/src/share/tools/ProjectCreator/WinGammaPlatformVC10.java. I applied it localy but some other OpenJDK developpers on WXP/VS2010 would benefit of this patch if it was applied to the OpenJDK7 forest. So I am wondering how to request a backport of this patch to the OpenJDK7/hotspot repository? Regards FA
Re: JDK 7 build errors on Windows XP
free.exe belongs to the package procps make/sanity-rules.gmk:61: *** multiple target patterns. Stop. You should downgrade the make.exe to the 3.80 version as explained in the README Kelly O'Hair a écrit : Yes. It is looking for the free command. It uses free to find the RAM memory size so it can set the java -Xmx memory setting to an appropriate value based on your machine (javac, jar etc.) I assume you need to install the cygwin package that includes this command, but I'm not sure what package that is. I normally just install all of cygwin. -kto PJ Pillai wrote: Hello, I using build b25 source code from - http://download.java.net/openjdk/jdk7/ I setup all the software as per readme html and setup my environment variable. When run make sanity, I am getting following error: c:\JDK7\javamake sanity /bin/sh: free: command not found make/sanity-rules.gmk:61: *** multiple target patterns. Stop. Is it looking for free command? I don't see that command in c:\cygwin\bin. Please help. Thanks Pravin
WXP: small build anomaly
Hi When building first OpenJDK in product mode and then build it again in debug mode, one gets a somewhat confusing anomaly: Z:\DEV\OpenJDK\builddir /X Le volume dans le lecteur Z s'appelle Developpement Le numéro de série du volume est A0AB-7CB1 Répertoire de Z:\DEV\OpenJDK\build 01/04/2008 09:15REP . 01/04/2008 09:15REP .. 01/04/2008 09:15REP WINDOW~1 windows-i586 01/04/2008 09:17REP WINDOW~2 WINDOW~1-debug 0 fichier(s)0 octets IMHO, it would be less confusing to create a 'windows-i586' directory for the release mode and a 'windows-i586-debug' directory for the debug mode to get something like 01/04/2008 09:15REP WINDOW~1 windows-i586 01/04/2008 09:17REP WINDOW~2 windows-i586-debug Francis
