This is the mail archive of the
mailing list for the Java project.
Re: testing an integrated build
On Fri, Dec 08, 2000 at 10:30:29AM -0800, Alexandre Petit-Bianco wrote:
> Tom Tromey writes:
> > Phil> 1) deps.mk references a bunch of .d files which don't exist
> > Phil> (commented out the Makefile's include statement to get around
> > Phil> this)
> > These should be created (as empty files) by libjava/configure. Why
> > aren't they built for you?
> I don't know. Once I worked around my thread problems, this is also
> what I hit on Solaris. Actually, only one `.d' file gets created, I
> never had a chance to find out why.
Same thing happended to me. I have my suspicions as to what's happening,
but here's a simple fix:
RCS file: /cvs/java/libgcj/libjava/configure.in,v
retrieving revision 1.69
diff -u -3 -p -r1.69 configure.in
--- configure.in 2000/11/29 04:53:36 1.69
+++ configure.in 2000/12/08 20:12:43
@@ -794,7 +794,10 @@ changequote(<<,>>)
d=`echo $f | sed -e 's,/[^/]*$,,'`
- : > $f
+ echo '' > $f
The files are are newlines instead of empties, so 'make' is a bit slower to
initialize, but not by much. Using touch(1) might be more appropriate.
(I know the advantages of using : instead, but I think Solaris'
extremely non-POSIX /bin/sh might be evaluating the : only on the first
time through the loop -- after all, : is a no-op, and it can't hurt to
elide the no-ops, right...? Bummer. This shell has bitten us before,
see http://gcc.gnu.org/ml/gcc-bugs/2000-11/msg00306.html for example.)
> > Phil> 2) compiling Boolean.java gives me:
> > Phil> /builddir/gcc/gcj -B/builddir/sparc-sun-solaris2.8/libjava/
> > Phil> -B/builddir/gcc/ -C -g -classpath
> > Phil> /builddir/sparc-sun-solaris2.8/libjava:/srcdir/libjava -d
> > Phil> /builddir/sparc-sun-solaris2.8/libjava java/lang/Boolean.java
> > Phil> java/lang/Boolean.java:25: Blank static final variable `FALSE' may not have
> > Phil> be initialized.
> > Alex will have to speak to this one. I haven't seen this problem.
> Well, I ran into it a few days ago, though on x86. This is our old
> friend in `end_artificial_method_body' There's a work around, but I
> want to work on this ASAP -- let me know if this fixes your build (it
> would definitively confirm a gc problem.)
> Index: parse.y
This works once the missing semicolon is added.
Now it gets down through XTollkit.java and then
find java gnu -type d -o -type f -name '*.class' | \
sed -e '/\/\./d' -e '/\/xlib/d' | \
../../zip/zip libgcj -@ -n .class
/bin/sh: ../../zip/zip: not found
gmake: *** [libgcj.zip] Error 1
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.