Dear Steffan,
On Fri, Dec 4, 2015 at 2:20 AM, Staffan Larsen <staffan.lar...@oracle.com>
wrote:
> Why is it a problem having executables and libraries in the same
> directory? It was a design choice we made to make things simpler.
It is a consistency problem. There would be no problem if this was the
common case, but it is a special case and anyone looking at this end up
paying for the special case. IMHO there is no need for this special case.
Carsten
>
> /Staffan
>
> > On 3 dec. 2015, at 18:13, Carsten Varming <varm...@gmail.com> wrote:
> >
> > 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
> >>>
> >>>
> >>>
> >>>
> >>>
>
>
