Following the instructions for the impatient, I did make images and then make
run-test-tier1.
Then after replacing the jtreg with the one Jon recommended, I did make
run-test-tier1 again.
Alan
> On Jan 5, 2018, at 6:32 PM, David Holmes wrote:
>
> On 6/01/2018 12:05 PM, Alan Snyder wrote:
>
On 6/01/2018 12:05 PM, Alan Snyder wrote:
The tests were run via make.
How exactly? And did you do "make test-image" first?
David
On Jan 5, 2018, at 4:13 PM, David Holmes wrote:
Alan,
Unclear how you ran the tests, but:
TEST RESULT: Error. Use -nativepath to specify the location of nativ
The tests were run via make.
> On Jan 5, 2018, at 4:13 PM, David Holmes wrote:
>
> Alan,
>
> Unclear how you ran the tests, but:
>
> TEST RESULT: Error. Use -nativepath to specify the location of native code
>
> indicates jtreg was not passed the -nativepath flag. That may or may not be a
>
Also:
jdk/internal/misc/JavaLangAccess/NewUnsafeString
seems to be a JDK 9 test, I don't see it in the current sources:
http://hg.openjdk.java.net/jdk/jdk10/file/ccbf1c998dd9/test/jdk/jdk/internal/misc
David
On 6/01/2018 8:43 AM, Alan Snyder wrote:
5 test failures remain using jtreg-4.2.0-ti
Alan,
Unclear how you ran the tests, but:
TEST RESULT: Error. Use -nativepath to specify the location of native code
indicates jtreg was not passed the -nativepath flag. That may or may not
be a build issue depending on whether the tests were executed directly
or via "make".
Cheers,
David
On 5/01/2018 11:09 PM, Randy Crihfield wrote:
This isn't a core lib test, or a vm test, or an install test, or any
other subcomponent.
The file you are changing belongs to core-libs.
When someone builds the OpenJDK, they need to know right off if they
actually built the OpenJDK w/o includin
5 test failures remain using jtreg-4.2.0-tip:
--
TEST: java/lang/String/nativeEncoding/StringPlatformChars.java
TEST JDK:
/Volumes/A/JDK/jdk10/build/macosx-x86_64-normal-server-release/images/jdk
ACTION: build -- Passed. Build successful
REASON:
I am trying jtreg-4.2.0-tip now.
Building jtreg using build-all.sh made some progress until:
2018-01-05 14:02:03 (5.89 MB/s) -
'/Volumes/A/JDK/jtreg/build/deps/ant/ant-1.7.0.jar' saved [1289806/1289806]
/Volumes/A/JDK/jtreg/build/deps/ant/ant-1.7.0.jar: OK
make: *** No rule to make target `391:
1. The build labelled jtreg-4.2.0-tip.tar.gz should work for you.
https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/
2. The build instructions are here:
http://openjdk.java.net/jtreg/build.html
See the section on using the "build-all.sh" script.
-- Jon
On 01/05/2018 01:35 PM,
Maybe not as easy as you expect:
ant -f make/build.xml
Buildfile: /Volumes/A/JDK/jtreg/make/build.xml
-init:
import-javahelp:
BUILD FAILED
/Volumes/A/JDK/jtreg/make/build.xml:246: Warning: Could not find file
/opt/javahelp/2.0/javahelp/lib/jh.jar to copy.
make -C make
…
../src/share/class
Alan,
I confirm there are problems with the jtreg builds from the Adopt
OpenJDK group. I'll investigate what we can do to fix this.
-- Jon
On 01/05/2018 12:36 PM, Jonathan Gibbons wrote:
That sounds like a problem using an older build of jtreg, from the
Adopt OpenJDK group. The tell-tale evi
That sounds like a problem using an older build of jtreg, from the Adopt
OpenJDK group. The tell-tale evidence is the Class-Path entry in the
jtreg.jar MANIFEST.MF file: does that entry include asmtools.jar?
There have been build changes for jtreg recently, that should have
addressed this pro
I am trying to build jdk10 on macOS 10.12.6. I got the basic build to work, but
some tests fail.
Most of the test failures complain about not finding jasm or jcoder. This is
odd because I downloaded jtreg-4.2-b11, which includes these classes, and the
classpath appears to be correct in the log.
This isn't a core lib test, or a vm test, or an install test, or any
other subcomponent.
When someone builds the OpenJDK, they need to know right off if they
actually built the OpenJDK w/o including the closed bits.
If this test fails, then there's no point in running any other test. It
is
14 matches
Mail list logo
