On 2017-09-27 11:36, Erik Joelsson wrote:
Ah good find and I stand corrected. That relative path check does need
to change for this to continue working as before.
What I don't understand is why the chmod is needed and why it's only
done when not running from a hg repo. We don't allow executable files
in the repository so if +x was required, then the tests would fail if
run from an hg repo.
I realize this was explained in the comment as I was sending this.
/Erik
/Erik
On 2017-09-27 11:28, Maurizio Cimadamore wrote:
I did a bit of digging on this one, I found out that the permissions
are indeed changed by make - see test/TestCommon.gmk:
# Prep for output
# Change execute permissions on shared library files.
# Files in repositories should never have execute permissions, but
# there are some tests that have pre-built shared libraries, and these
# windows dll files must have execute permission. Adding execute
# permission may happen automatically on windows when using certain
# versions of mercurial but it cannot be guaranteed. And blindly
# adding execute permission might be seen as a mercurial 'change', so
# we avoid adding execute permission to repository files. But testing
# from a plain source tree needs the chmod a+rx. Applying the chmod to
# all shared libraries not just dll files. And with CYGWIN and sshd
# service, you may need CYGWIN=ntsec for this to work.
prep:
@$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR)
@$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)`
@if [ ! -d $(TEST_ROOT)/../.hg ] ;
then \
$(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name
\*.so \) \
-exec $(CHMOD) a+rx {} \;
; \
fi
This part seems to be responsible for changing the permissions on the
said lib files. That said, TestCommon.gmk is essentially the same as
it was in jdk10 unconsolidated, but yet the problem cannot be
reporoduced in the latest unconsolidated jdk10 repo. So, I believe
something is up. More specifically, this test:
if [ ! -d $(TEST_ROOT)/../.hg ] ;
then \
was probably failing before, causing the permission changing branch
not to be taken?
Maurizio
On 26/09/17 12:10, Maurizio Cimadamore wrote:
On 26/09/17 07:13, Alan Bateman wrote:
On 25/09/2017 21:35, Maurizio Cimadamore wrote:
On 25/09/17 20:58, Alan Bateman wrote:
On 25/09/2017 20:11, Jonathan Gibbons wrote:
Erik,
It could be a feature of the build (i.e. test makefiles) to
verify that no source-controlled files were modified in the
course of a test run.
Something fishy in this thread as these tests have historically
not changed the permissions of these libraries. So I'm curious
how they were run, I wonder in case they were changed by a make
file instead.
make test TEST=jdk_lang
AFAIK, this should be the correct way of invoking tests from make?
I assume this make file must be running chmod, not the tests
themselves as otherwise this issue would have been noticed a long
time ago. I suspect many people run jtreg directly in their local
environment rather than the make file.
Note that I've been running tests this way over the last 2-3 years,
and this only started to happen after the move to consolidated repo.
That's why I correlated the two things.
Maurizio
In any case, these older tests predate build test support for
compiling native code and probably should be migrated anyway.
-Alan
