Dear David,
I think I finally understand what is going on now. :)
The command "make build-test-hotspot-jtreg-native" populates
$(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/ with ".so" files using
sub-directories of $(OUTPUTDIR)/support/test/hotspot/jtreg/native/support/
as scratch space for each test.
The command "make test-image-hotspot-jtreg-native" (which I didn't run in
my sequence of commands above) copies all files
in $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/
to $(OUTPUTDIR)/images/test/hotspot/jtreg/native/ . Notice the lacking
"/lib" in the target.
Jtreg is passed the parameter
"-nativepath:$(TESTNATIVE_DIR)/hotspot/jtreg/native". Jtreg then use the
native path to set both system properties: test.nativepath and
java.library.path.
This leaves a lot to be desired. Jtreg expects all library files and
executables to be in the same directory (there are no executables in the
hotspot tests, but the jdk contains one). There is separation between
libraries and executables everywhere except
in $(OUTPUTDIR)/images/test/{hotspot,jdk}/jtreg/native/ because jtreg and
jdk/test/native_sanity/simplenativelauncher/ProgramTest.java expect
executables to be in the same directory as libraries. I have never seen
that before. Notice that this makes the step copying the executables into
the images sub-directory mandatory.
The right thing seems to be to fix jtreg to maintain separation. Something
as simple as setting java.library.path to test.nativepath + "/lib" and
force a standard layout with bin and lib sub-directories would be an
improvement. Perhaps even extend jtreg it to allow separation between
libraries and executables from different tests (test A should not have
access to libraries from test B).
I will drop this issue now that I have a way to execute tests containing
native code, but it would be nice if someone working on jtreg would make it
possible keep executables separate from libraries.
Carsten
On Thu, Dec 3, 2015 at 2:15 AM, David Holmes <david.hol...@oracle.com>
wrote:
> cc'ing build-dev
>
> On 2/12/2015 1:28 AM, Carsten Varming wrote:
>
>> Dear David,
>>
>> See inline.
>>
>> On Tue, Dec 1, 2015 at 2:26 AM, David Holmes <david.hol...@oracle.com
>> <mailto:david.hol...@oracle.com>> wrote:
>>
>> Hi Carsten,
>>
>> On 1/12/2015 8:21 AM, Carsten Varming wrote:
>>
>> Dear Ioi,
>>
>> Absolutely,
>>
>> diff -r 7606b8556225 test/Makefile
>> --- a/test/Makefile Thu Nov 26 13:13:03 2015 +0100
>> +++ b/test/Makefile Mon Nov 30 17:20:30 2015 -0500
>> @@ -156,7 +156,7 @@
>> TESTNATIVE_DIR = $(JPRT_TESTNATIVE_PATH)
>> endif
>> ifdef TESTNATIVE_DIR
>> - JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>> "$(TESTNATIVE_DIR)/hotspot/jtreg/native")
>> + JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>> "$(TESTNATIVE_DIR)/hotspot/jtreg/native/lib")
>> endif
>>
>>
>> In hotspot/make/test/JtregNative.gmk we have:
>>
>> BUILD_HOTSPOT_JTREG_OUTPUT_DIR :=
>> $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native
>>
>>
>> The SetupTestFilesCompilation macro adds the subdirectory "lib" to the
>> path such that the ".so" files (or ".dylib" files) end up in
>> $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native/lib.
>>
>
> Thanks for that. Tracing through these makefile macros is far too painful.
> I wish there were some way to see what they looked like once expanded.
>
> so the above patch should not be needed.
>>
>>
>> Without the patch the following sequence of commands fails:
>> sh configure --enable-debug
>> make images
>> make build-test-hotspot-jtreg-native
>> cd hotspot/test
>> make TESTDIRS=runtime/SameObject
>>
>> TESTNATIVE_DIR=../../build/macosx-x86_64-normal-server-fastdebug/support/test
>> JT_HOME=/Users/cvarming/workspace/jtreg/jtreg
>> JAVA_HOME=../../build/macosx-x86_64-normal-server-fastdebug/images/jdk
>> PRODUCT_HOME=$JAVA_HOME jtreg_tests
>>
>> TEST RESULT: Failed. Execution failed: `main' threw exception:
>> java.lang.UnsatisfiedLinkError: no SameObject in java.library.path
>>
>> and java.library.path is defined
>> by:
>> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native
>>
>
> What I see in a JPRT build is simply:
>
> (cd /scratch/hotspot/make/test && make -r -R -I /scratch/make/common
> SPEC=/scratch/build/linux-x86-normal-clientANDserver-fastdebug/spec.gmk
> MAKE_LOG_FLAGS="" LOG_LEVEL=debug -f JtregNative.gmk \
> test-image-hotspot-jtreg-native)
>
>
>> On the other hand, with the patch the test runs fine. Looking at
>> SameObject.jtr I can
>> see:
>> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native/lib,
>> i.e., "/lib" is appended to the path and the test pass.
>>
>> So I wonder, are these tests run by JPRT? And if they are, then what I
>> am doing wrong?
>>
>
> Yes they are run (or some subset thereof). The -nativepath that gets
> passed to jtreg does not include a lib component.
>
> I'm afraid I don't know what is going wrong.
>
> David
> -----
>
> BTW. This paths above are taken from runs on my mac. The problem also
>> occurs on my Linux desktop.
>>
>> Carsten
>>
>> David
>> -----
>>
>>
>>
>>
>> # Expect JPRT to set JPRT_ARCHIVE_BUNDLE (path to zip bundle
>> for results)
>>
>> Carsten
>>
>> On Mon, Nov 30, 2015 at 5:17 PM, Ioi Lam <ioi....@oracle.com
>> <mailto:ioi....@oracle.com>> wrote:
>>
>> Your patch seems to have been stripped by the mailer. Is it
>> possible to
>> just include it as plain text in the e-mail?
>>
>> Thanks
>> - Ioi
>>
>>
>> On 11/30/15 1:34 PM, Carsten Varming wrote:
>>
>> Hi everyone,
>>
>> I was recently trying to run some tests that use native
>> code, e.g.,
>> hotspot/runtime/SameObject/SameObject.java and found
>> that I had to apply
>> the attached diff to get the tests to work.
>>
>> I am doing something wrong or is this a trivial bug?
>>
>> Carsten
>>
>>
>>
>>
>>
