If you don't have a previous incarnation of GCJ installed...

Fri Mar 9 15:30:00 GMT 2001

On Sat, Mar 10, 2001 at 12:11:26PM +1300, Bryce McKinlay wrote:
> Zack Weinberg wrote:
>> > This causes ltconfig to conclude that no, gcj doesn't support -c with
> > -o. So libtool tries to work around that with mv. That in turn
> > causes ~500 spurious testsuite failures, because the mv from fileutils
> > 4.0 rejects an attempt to move a file onto itself.
> >
> > Sticking -fclasspath=${srcdir} into $GCJ in configure.in isn't good
> > enough, because gnu/classpath/Configuration.java doesn't exist yet,
> > and it tries to read that.
>> Yeah. But this just means you need to "make install" before "make check",
> right? Or is the problem affecting you elsewhere?

I'm not aware of any other places where this causes a problem. This
doesn't mean there aren't any. Install before check is not going to
be popular with the wider user base, btw.
> My preferred solution is for libtool to stop doing silly tests! (there has
> never been a GCJ that doesn't support "-c -o"), but don't think Oliva liked
> that idea. Ideally we could put a flag in ltcf-gcj.sh that tells it not to
> bother, but I don't see an obvious way to do that with the current libtool.

I s'pose you could have configure edit the generated libtool after
LT_AC_PROG_GCJ is done.
_My_ recommended solution would be for "class foo {}" not to require
any external data in order to generate an object file, but I have no
idea what causes the requirement; maybe this is genuinely necessary.
Libtool does have to be fixed somehow - later in the same test
sequence it tries to feed C to jc1.
zw