libjava - PR1343 'compilation from bytecode' failure - libtool bug

[Zack Weinberg <zack at codesourcery dot com>]

I've been getting

                === libjava tests ===
FAIL: PR1343 compilation from bytecode
FAIL: PR1343 -O compilation from bytecode

for some time now.  I decided to dig into this a little, and it turns
out to be a bug in libtool.

The failing command is (the equivalent of)

CLASSPATH=.:.. ../libtool --silent --tag=GCJ --mode=compile \
  ../../../gcc/gcj -B../../../gcc/ --encoding=UTF-8 -B.. \
  -c -o PR1343\$1\$x1.o PR1343\$1\$x1.class

(line breaks, here and henceforth, added by me for readability)

and the failure is of the form

Assembler messages:
FATAL: can't create .libs/PR1343-B../../../gcc/.o: No such file or directory

The dollar signs in the filename arguments might cause one to suspect
a problem with shell quoting, and indeed this is the case.  Removing
the --silent from the libtool command line reveals that the command
libtool thinks it is executing is

../../../gcc/gcj -B../../../gcc/ --encoding=UTF-8 -B.. \
  -c PR1343\$1\$x1.class -v -fPIC -o .libs/PR1343$1$x1.o

Note the absence of backslashes on the object file argument.  Wading
through sh -x ../libtool output reveals that this is the command line
before it is run through 'eval':

+ command=../../../gcc/gcj -B../../../gcc/ --encoding=UTF-8 -B.. \
    -c PR1343\$1\$x1.class -v -fPIC -o .libs/PR1343$1$x1.o
+ rm -f '.libs/PR1343$1$x1.o' ''
+ /bin/echo '../../../gcc/gcj -B../../../gcc/ --encoding=UTF-8 -B.. \
     -c PR1343\$1\$x1.class -v -fPIC -o .libs/PR1343$1$x1.o'
+ eval '../../../gcc/gcj -B../../../gcc/ --encoding=UTF-8 -B.. \
     -c PR1343\$1\$x1.class -v -fPIC -o .libs/PR1343$1$x1.o'
++ ../../../gcc/gcj -B../../../gcc/ --encoding=UTF-8 -B.. \
     -c 'PR1343$1$x1.class' -v -fPIC -o .libs/PR1343-B../../../gcc/.o

The eval of course replaces $1 with the argument to the shell script, in
this case '-B../../../gcc/' since some shifts have been applied.  $x1
is undefined, so it simply vanishes.

I note that the .class file got run through a sed operation to escape
shell metacharacters:

+ lastarg=PR1343$1$x1.class
+ srcfile=-v
++ /bin/echo 'XPR1343$1$x1.class'
++ sed -e '1s/^X//' -e 's/\([\\`\\"$\\\\]\)/\\\1/g'
+ lastarg=PR1343\$1\$x1.class


but the object file did not.  However, this is not the sole bug,
because under slightly different conditions - such as when this is
being run from DejaGNU - it's the .class file whose name gets mangled.

Alexandre, would you mind looking into this?

zw