libgcj.spec: jc1 directive unused?

[Jeff Sturm <jeff dot sturm at appnet dot com>]

I just tried to checkout/build gcc and libgcj for a target that needs
sjlj-exceptions.  The build failed with undefined references to
_Jv_Throw, which shouldn't have been referenced at all when
sjlj-exceptions are used.

A little investigation shows that some of the directives in libgcj.spec
aren't getting passed to jc1.  Here's the generated libgcj.spec:


#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename lib liborig
*lib: -lgcj -lm -lgcjgc -lpthread -lzgcj   -ldl %(liborig)

*jc1:  -fuse-divide-subroutine -fsjlj-exceptions
-fasynchronous-exceptions

#
# libgcc should really be a shared library.  This is a design flaw
# that causes no end of mysterious problems.  If we are using the
# GNU linker, force parts of libgcc into the program file rather
# than picking bits up from various shared libraries.
#
%rename startfile startfileorig
*startfile: %(startfileorig) -u data_start -lgcjdata -u __rethrow -u
__frame_state_for -lgcc


and here's the output of a compile, with verbose on:

[jsturm@toronto libjava]$ gcj -v -fassume-compiled
-L/home/jsturm/Cygnus/libgcj/build/alphapca56-unknown-linux-gnu/libjava
-g -c  -fPIC ../../../libjava/java/lang/Thread.java -o
java/lang/.libs/Thread.lo
Reading specs from
/opt/gcj/lib/gcc-lib/alphapca56-unknown-linux-gnu/2.96/specs
Reading specs from
/home/jsturm/Cygnus/libgcj/build/alphapca56-unknown-linux-gnu/libjava/libgcj.spec
rename spec lib to liborig
rename spec startfile to startfileorig
gcc version 2.96 20000713 (experimental)
 /opt/gcj/lib/gcc-lib/alphapca56-unknown-linux-gnu/2.96/jc1
../../../libjava/java/lang/Thread.java -quiet -dumpbase Thread.java -g
-version -fassume-compiled -fPIC -o /tmp/ccn5Zm5G.s
GNU Java version 2.96 20000713 (experimental)
(alphapca56-unknown-linux-gnu) compiled by GNU C version 2.96 20000430
(experimental).
 as -o java/lang/.libs/Thread.lo /tmp/ccn5Zm5G.s


So there's no -fsjlj-exceptions anywhere in there.  That explains my
problem.  Any opinions if this is a problem in libgcj.spec, or in the
gcc language driver?  I'll be happy to file a PR, once I'm a little
clearer on it.


--
Jeff Sturm
jeff.sturm@appnet.com