New scribbling over $srcdir/libjava

Loren James Rittle rittle@latour.rsch.comm.mot.com
Wed Jun 11 01:15:00 GMT 2003


This issue caught by one of the daily regression checks I run.  Neil's
-r1.127 patch to gcc/java/lang.c appears to be the guilty party.  At
some point in the last 48 hours, libjava started creating all .d files
in $srcdir (I'm sure it used to do so in $objdir).  At about the same
time, it started leaving an empty .d file in $objdir.  AFAIK, this
doesn't really affect full, clean bootstrap in any manner but it is
clearly not right w.r.t. command-line given and does monkey-up a clean
$srcdir (Aside: fastjar, g77 and gcj documentation are the only
remaining non-conformists when both $parsedir and $docobjdir are set
properly in gcc/Makefile.in).

After observing that libjava didn't change the command line it passes
to gcj, running a typical jc1 command, extracted by diving into the
libtool generated gunk, under truss:

truss [...]/jc1 $srcdir/libjava/java/io/PrintStream.java [...] \
  -MD -MT java/io/PrintStream.lo -MF java/io/PrintStream.d -o [...]

open("java/io/PrintStream.d",0x601,0666)         = 3 (0x3)
open("[$srcdir]/java/io/PrintStream.d",0x601,0666) = 3 (0x3)
open("java/io/.libs/PrintStream.da",0x2,0666)    ERR#2 'No such file [...]'

I'd think it must be a bug to ignore the file path that the user provided.

Regards,
Loren



More information about the Java mailing list