configure should provide better error reports about bootjvm binaries

FULL PRODUCT VERSION :
N/A - problem is in the build autoconf system.

ADDITIONAL OS VERSION INFORMATION :
Linux dpointo8-ThinkPad-T400 3.2.0-56-generic-pae #86-Ubuntu SMP Wed Oct 23 17:51:27 UTC 2013 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
Whilst running configure, the script aborted - complaining of the java binary being missing from the bootjvm. However, on investigation, the file was incontrovertibly present but it did not have execute permissions set. On enabling execute permission, the script ran successfully to completion.

ADDITIONAL REGRESSION INFORMATION:
N/A - problem is in the build autoconf system.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Remove execution permissions for one, or more, of the binaries in the bootjvm.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The binary file should have been reported extant, but non-executable.
ACTUAL -
The binary file was reported as missing.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
N/A - problem is in the build autoconf system.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The workaround is to ensure that all binaries in the bootjvm have execute permissions before running the configure script.

However by way of incorporating the above into the configure step, the patch defined by the following (I would have attached the webrev, but no such facility appears to exist on defect creation) is suggested ...

diff -r 174a54ce39c4 -r 0b7cfe8297d9 common/autoconf/boot-jdk.m4
--- a/common/autoconf/boot-jdk.m4Thu Oct 10 14:58:19 2013 +0200
+++ b/common/autoconf/boot-jdk.m4Wed Nov 13 19:28:34 2013 +0000
@@ -23,6 +23,10 @@
 # questions.
 #
 
+#
+# Portions Copyright (c) 2013 IBM Corporation
+#
+
 # Execute the check given as argument, and verify the result
 # If the Boot JDK was previously found, do nothing
 # $1 A command line (typically autoconf macro) to execute
@@ -32,17 +36,19 @@
     # Now execute the test
     $1
 
- # If previous step claimed to have found a JDK, check it to see if it seems to be valid.
+ # If previous step claimed to have found a JDK, check it to see if it seems
+ # to be valid.
     if test "x$BOOT_JDK_FOUND" = xmaybe; then
- # Do we have a bin/java?
- if test ! -x "$BOOT_JDK/bin/java"; then
- AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK did not contain bin/java; ignoring])
+ # Test for a bin/java?
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(JAVA,java,continue)
+ if test "j$JAVA" = j; then
+ AC_MSG_NOTICE([Ignoring])
         BOOT_JDK_FOUND=no
       else
         # Do we have a bin/javac?
- if test ! -x "$BOOT_JDK/bin/javac"; then
- AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK did not contain bin/javac; ignoring])
- AC_MSG_NOTICE([(This might be an JRE instead of an JDK)])
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(JAVAC,javac,continue)
+ if test "j$JAVAC" = j; then
+ AC_MSG_NOTICE([Ignoring - This might be an JRE instead of an JDK)])
           BOOT_JDK_FOUND=no
         else
           # Do we have an rt.jar? (On MacOSX it is called classes.jar)
@@ -196,19 +202,51 @@
   fi
 ])
 
-# Check that a command-line tool in the Boot JDK is correct
+###############################################################################
+#
+# Check that a command-line tool in the Boot JDK is present and executable
 # $1 = name of variable to assign
 # $2 = name of binary
-AC_DEFUN([BOOTJDK_CHECK_TOOL_IN_BOOTJDK],
+# $3 = error flag - continue if set to 'continue' or not set, abort, via
+# AC_MSG_ERROR, otherwise
+AC_DEFUN([BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT],
 [
- AC_MSG_CHECKING([for $2 in Boot JDK])
+ case "f$3" in
+ f|+ fcontinue) Action=continue ;;
+ *) Action=abort ;;
+ esac
+
+ AC_MSG_CHECKING([for $2 in Boot JDK - $Action on error ])
+
+ # Set the given var for the binary
   $1=$BOOT_JDK/bin/$2
- if test ! -x [$]$1; then
- AC_MSG_RESULT(not found)
- AC_MSG_NOTICE([Your Boot JDK seems broken. This might be fixed by explicitely setting --with-boot-jdk])
- AC_MSG_ERROR([Could not find $2 in the Boot JDK])
+ if test ! -f [$]$1; then
+ Result="not found"
+ Notice="Your Boot JDK seems broken. This might be fixed by explicitly setting --with-boot-jdk"
+ Error="Could not find $2 in the Boot JDK"
+ elif test ! -x [$]$1; then
+ Result="not executable"
+ Notice="Your Boot JDK seems broken. This might be fixed by explicitly making [$]$1 executable"
+ Error="Could not find executable $2 in the Boot JDK"
+ else
+ Result=ok
   fi
- AC_MSG_RESULT(ok)
+ # Report the result
+ AC_MSG_RESULT($Result)
+
+ # Now do final (non-)error handling
+ if test "r$Result" != rok; then
+ # As it's no longer any use (coz the binary's not valid), reset the variable
+ $1=
+ # Then report the error
+ AC_MSG_NOTICE($Notice)
+
+ # Abort if flagged so to do
+ if test "a$Action" != acontinue; then
+ AC_MSG_ERROR($Error)
+ fi
+ fi
 ])
 
 ###############################################################################
@@ -275,13 +313,13 @@
   AC_SUBST(BOOT_JDK)
 
   # Setup tools from the Boot JDK.
- BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVA,java)
- BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAC,javac)
- BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAH,javah)
- BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAP,javap)
- BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAR,jar)
- BOOTJDK_CHECK_TOOL_IN_BOOTJDK(RMIC,rmic)
- BOOTJDK_CHECK_TOOL_IN_BOOTJDK(NATIVE2ASCII,native2ascii)
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(JAVA,java,abort)
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(JAVAC,javac,abort)
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(JAVAH,javah,abort)
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(JAVAP,javap,abort)
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(JAR,jar,abort)
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(RMIC,rmic,abort)
+ BOOTJDK_CHECK_TOOL_IN_BOOTJDK_WITH_OPT_ABORT(NATIVE2ASCII,native2ascii,abort)
 
   # Finally, set some other options...


Note also that, whilst investigating the problem, I noticed a number of instances of near-identical functionality implemented via cut & paste - the above utilizes the basic tenet of SPoD (Single Point of Definition) thus removing potential copy & paste errors that might accrue from failing to alter functionality in all identified cases.

It is suggested that resolution of this defect would further enhance the usability of the build system for all users - especially newbie users.