----- Original Message -----
I have pointed out some changes below, but there is a serious
problem.
You are checking for the system arch using uname but the
java architecture may not be the same.
For example we run 32-bit jdk on a 64bit system, this will cause test
failures
since we will be using the wrong path names.
You can use the following to determine the java arch.
% java -XshowSettings:props -version 2>&1 | grep os.arch
This doesn't work (at least for me) unless the '-version' is removed.
There was a bug which was fixed in 7u4/u6.
I also note that this seems to only be present in 7 and later (i.e. not 6), not
that this will matter in this case.
Correct, 7 and above.
Kumar
other diffs follow.....
@@ -22,16 +22,17 @@
# questions.
# @test runtest.sh
-# @bug 9999999
+# @bug 7190813
# @summary Native code linked against libjawt.so should be
sufficent
for libjawt.so to be found
# @run shell runtest.sh
-if [ "${TESTSRC}" = "" ]
-then TESTSRC=.
+set -x
+
+if [ "${TESTSRC}" = "" ]; then
+ TESTSRC=.
fi
-if [ "${TESTJAVA}" = "" ]
-then
+if [ "${TESTJAVA}" = "" ]; then
PARENT=`dirname \`which java\``
TESTJAVA=`dirname ${PARENT}`
echo "TESTJAVA not set, selecting " ${TESTJAVA}
@@ -46,14 +47,10 @@
PS=":"
FS="/"
;;
- SunOS | Windows_* )
- echo "Test passed; only valid for Linux"
+ * )
+ echo "Warning: test passes vacuously for non linux systems"
exit 0;
;;
- * )
- echo "Unrecognized system!"
- exit 1;
- ;;
esac
# Get ARCH specifics
@@ -71,13 +68,13 @@
gcc -v> /dev/null 2>&1
if [ "$?" != 0 ] ; then
- echo "No compiler found"
- exit 1
+ echo "Warning: No gcc compiler found, test passes vacuously"
+ exit 0
fi
-JAVAC=${TEST_JAVA}${FS}bin${FS}javac
-JAVAH=${TEST_JAVA}${FS}bin${FS}javah
-JAVA=${TEST_JAVA}${FS}bin${FS}java
+JAVAC=${TESTJAVA}${FS}bin${FS}javac
+JAVAH=${TESTJAVA}${FS}bin${FS}javah
+JAVA=${TESTJAVA}${FS}bin${FS}java
$JAVAC -d . ${TESTSRC}${FS}TestJawt.java || exit 1
$JAVAH TestJawt || exit 1
Thanks
Kumar
On 08/13/2012 10:39 AM, Anthony Petrov wrote:
The test looks great, and I like that it doesn't depend on the
JAWT
machinery, but tests the actual problematic RPATH entry only.
I generally go for tests that verify behaviour (that jawt-linked
programs are working) rather than implementation details (which
changed,
for example, when we switched from LD_LIBRARY_PATH to RPATHS).
+1 from me.
Yes, good to have something that guards us from changing something
unintentionally. Looks fine to me too.
Cheers,
Omair
