[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.(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.(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.(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) ... 9 more
Re: JI-9008287 - configure should provide better error reports about bootjvm binaries
Hi David , On Fri, 2013-11-22 at 01:45 +1000, David Holmes wrote: > Please do. I moved the JI issue to JDK: > > https://bugs.openjdk.java.net/browse/JDK-8028794 > > Not sure what your plans was for getting this pushed but we are in a > phase were an approval process has to be followed to make changes to 8. > The 9 forest will hopefully be open "real soon now" and this could be > backported to 8u after that. > > Thanks, > David If the change were a showstopper then I would suggest that it be pushed sooner rather than later; However, it isn't, so I won't :-) Change made & webrev.03 generated, I'm just awaiting Neils' return to get it posted... Rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe
Re: [7u]: help on jdk/make/common/shared/Defs-windows.gmk
I did some experiments and looked closer at the code. I missed some details in my earlier analysis. Here is what is supposed to happen: FullPath is a macro that takes a path and converts it to mixed style (c:/) path without spaces. Depending on whether the input contains a space (the test $(if $(word 2,$1))) two different approaches to this are employed. If there is a space, cygpath is executed as we do not know of a way to convert to dos short names without it. If there is no space, we avoid the overhead of executing an external command and instead use a combination of $(realpath) and some make macro magic. $(realpath) makes a path absolute and canonical. Then the MixedPath macro handles the conversion of /cygdrive/c to C:. It seems to me like your make binary is failing the realpath call. I have no idea how this happened and have never seen it before. One thing I am certain of is that changing the test to $(if $(word 1,$1) is not the correct solution. It's basically changing it to "if true". Could you try a couple of tests of realpath in your test.mk? Something like: $(info realpath . $(realpath .)) /Erik On 2013-11-20 21:11, Francis ANDRE wrote: 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
hg: jdk8/build/jdk: 8028645: [infra] purge applet demos from the Solaris distros
Changeset: 6c1f5c7baab0 Author:ksrini Date: 2013-11-21 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6c1f5c7baab0 8028645: [infra] purge applet demos from the Solaris distros Reviewed-by: erikj ! makefiles/CompileDemos.gmk
Re: JI-9008287 - configure should provide better error reports about bootjvm binaries
On 22/11/2013 1:02 AM, Dave Pointon wrote: Hi again, Magnus , On Fri, 2013-11-22 at 00:35 +1000, David Holmes wrote: On 21/11/2013 11:05 PM, Magnus Ihse Bursie wrote: On 2013-11-19 13:47, Dave Pointon wrote: The updated webrev can be found at http://cr.openjdk.java.net/~ngmr/JI-9008287/webrev.02/ The actual code looks better, but I'm not so sure about the copyright header. The actual change was indeed very small, and is more or less a variation of what I suggested earlier. If you insist on keeping it, I'll need to check with legal support first. Otherwise I think it looks good (but I'm not a formal reviewer). That is my position as a Reviewer as well. Meanwhile we should see about migrating the bug from JI to JDK. Thanks, David /Magnus I've just received an update WRT the copyright change - it seems that I was inadvertently over zealous in the application of instructions and given the (lack of the) magnitude of the change, I should not have included the copyright statement. Would you like me to generate and indeed post, a new webrev ? Please do. I moved the JI issue to JDK: https://bugs.openjdk.java.net/browse/JDK-8028794 Not sure what your plans was for getting this pushed but we are in a phase were an approval process has to be followed to make changes to 8. The 9 forest will hopefully be open "real soon now" and this could be backported to 8u after that. Thanks, David Rgds ,
Re: JI-9008287 - configure should provide better error reports about bootjvm binaries
On 21/11/2013 11:05 PM, Magnus Ihse Bursie wrote: On 2013-11-19 13:47, Dave Pointon wrote: The updated webrev can be found at http://cr.openjdk.java.net/~ngmr/JI-9008287/webrev.02/ The actual code looks better, but I'm not so sure about the copyright header. The actual change was indeed very small, and is more or less a variation of what I suggested earlier. If you insist on keeping it, I'll need to check with legal support first. Otherwise I think it looks good (but I'm not a formal reviewer). That is my position as a Reviewer as well. Meanwhile we should see about migrating the bug from JI to JDK. Thanks, David /Magnus
Re: Improving the management and accessibility of the handling of JDK variants
Hiya Magnus , On Thu, 2013-11-21 at 14:18 +0100, Magnus Ihse Bursie wrote: > On 2013-11-18 21:05, David Holmes wrote: > > Of course these configuration points have been defined based on our > > needs for the Oracle JDK versus OpenJDK, so there is no claim of > > general applicability or suitability for all potential users who want > > to customize the build and/or sources. Happy to adapt in reasonable > > ways of course. > > I agree. > > We have a couple of systems in place for building with custom additions, > and different variants. But they are adapted to what we needed. > > Dave, if you can specify more precisely what kind of additions and > alterations you need, I can suggest ways to do that, that is likely to > fit in the OpenJDK build system, and that might help to develop these > hooks into more generally useful ones. But unfortunately it is quite > dependent on exactly what kind of additions that are needed. > > /Magnus > In the process of attempting to describe the changes I'm playing with, I've realized that I've made a coupla wrong assumptions and completely inflexible and thus inappropriate, design decisions. I'll post further once I believe I have a more generally applicable/useful model to impart ... Rgds, -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe
Re: Improving the management and accessibility of the handling of JDK variants
On 2013-11-18 21:05, David Holmes wrote: Of course these configuration points have been defined based on our needs for the Oracle JDK versus OpenJDK, so there is no claim of general applicability or suitability for all potential users who want to customize the build and/or sources. Happy to adapt in reasonable ways of course. I agree. We have a couple of systems in place for building with custom additions, and different variants. But they are adapted to what we needed. Dave, if you can specify more precisely what kind of additions and alterations you need, I can suggest ways to do that, that is likely to fit in the OpenJDK build system, and that might help to develop these hooks into more generally useful ones. But unfortunately it is quite dependent on exactly what kind of additions that are needed. /Magnus
Re: JI-9008287 - configure should provide better error reports about bootjvm binaries
On 2013-11-19 13:47, Dave Pointon wrote: The updated webrev can be found at http://cr.openjdk.java.net/~ngmr/JI-9008287/webrev.02/ The actual code looks better, but I'm not so sure about the copyright header. The actual change was indeed very small, and is more or less a variation of what I suggested earlier. If you insist on keeping it, I'll need to check with legal support first. Otherwise I think it looks good (but I'm not a formal reviewer). /Magnus
Re: JI-9008287 - configure should provide better error reports about bootjvm binaries
Hi again, Magnus , On Fri, 2013-11-22 at 00:35 +1000, David Holmes wrote: > On 21/11/2013 11:05 PM, Magnus Ihse Bursie wrote: > > On 2013-11-19 13:47, Dave Pointon wrote: > >> The updated webrev can be found at > >> http://cr.openjdk.java.net/~ngmr/JI-9008287/webrev.02/ > > > > The actual code looks better, but I'm not so sure about the copyright > > header. The actual change was indeed very small, and is more or less a > > variation of what I suggested earlier. > > > > If you insist on keeping it, I'll need to check with legal support > > first. Otherwise I think it looks good (but I'm not a formal reviewer). > > That is my position as a Reviewer as well. > > Meanwhile we should see about migrating the bug from JI to JDK. > > Thanks, > David > > > /Magnus > I've just received an update WRT the copyright change - it seems that I was inadvertently over zealous in the application of instructions and given the (lack of the) magnitude of the change, I should not have included the copyright statement. Would you like me to generate and indeed post, a new webrev ? Rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe
Re: RFR: Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop
On 2013-11-21 07:45, Francis ANDRE wrote: 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. Francis, In JDK8, we have completely rewritten the build system from scratch. One of the guiding principles was that it should be, as far as possible, self diagnostic. If a dependency is missing, it should be clearly written, and -- if possible -- with guidelines on how to fix the problem. We are not 100% there, but much closer than in the old (pre-JDK8) build system. It is also much more robust on platforms such as Windows. If you need to build JDK7, then that will unfortunately not help you. There is not likely to be much work spend in fixing the old build system in JDK7 either, nor is it likely that the new JDK8 build system will be backported to JDK7. If it is possible, I'd suggest that you try to build and use JDK8 instead. It will definitely provide a much smoother experience for you. /Magnus
Re: LIBARCHNAME in CompileLauncher.gmk
On 2013-11-19 19:46, Jeremy Manson wrote: Not really. We have to keep the patch to the launcher going anyway, so having this be part of it isn't a big deal. But it should definitely either be corrected or removed, because if someone did depend on its behavior being correct, then they would break 32-bit x86 builds. We'll remove it. Too late for that for jdk8, though. I created https://bugs.openjdk.java.net/browse/JDK-8028770 to track this. Thank you for your bug report! /Magnus
Re: RFR: Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop
On 2013-11-21 10:10, Erik Joelsson wrote: On 2013-11-21 07:57, Francis ANDRE wrote: 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 Then this is something we still need to fix. I wasn't aware of this until now. I wanted to investigate this so configured using --with-jtreg=/path/to/jtreg/dir and the ran make test. Looks to me like a lot of tests are running and passing. What specific issue do you have with testing on windows? /Erik
Re: RFR: Bug ID: 9007227: - make/sanity-rules.gmk:61: *** multiple target patterns. Stop
On 2013-11-21 07:57, Francis ANDRE wrote: 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 Then this is something we still need to fix. I wasn't aware of this until now. /Erik
