internal compiler error: in size_binop

Mon Jan 24 05:45:00 GMT 2005

On Tue, 2005年01月18日 at 14:57, Tom Tromey wrote:
> >>>>> "Brian" == C Brian Jones <cbj@gnu.org> writes:
>> Brian> I ran into some trouble trying to build cp-tools with gcj. I can go do
> Brian> as the error suggests to submit a bug report, just wondering if this is
> Brian> something that might be fixed in a more recent gcj?
>> Possibly, but hard to say for sure without trying it.
>> Brian> ../src/gnu/classpath/tools/JavahMain.java:30: internal compiler error:
> Brian> in size_binop, at fold-const.c:1438
>> Looks similar to PRs 7883 (closed), 8410 (closed), 15888 (closed),
> and 18362 (open).

I updated to gcc-head and this particular problem went away. A
different error was shown instead. I was able to deduce that this new
error was due to including glibj.zip from Classpath in the -classpath
command argument. The reason I did this was to get the XML libraries
not currently merged into gcj from classpath. I got around this by
zipping up just the parts I needed in classpath and using those in
-classpath instead. Attempting to compile the last release of GNU JAXP
failed as well sort of forcing my hand.
This, and another library dependency, brought me to my next problem. 
After futzing around with this most of the afternoon I have not been
able to determine the proper incantation in automake to properly link in
.jar or .zip files produced by external sources. The _SOURCES directive
prohibits the use of variables determined by configure, so finding the
.jar/.zip file and substituting it means the use of _SOURCES can't be
the answer.
After some testing I have determined that 
gcj -shared -o liblib.so lib.jar will produce a liblib.so that can be
used as a library for another class as below.
gcj --main=test -o test test.java liblib.so
What doesn't seem to work for me is specifying something like
gcj --main=test -o test test.java -llib
[cbj@fencepost tmp]$ gcj --main=test -o test test.java -llib
/usr/bin/ld: cannot find -llib
collect2: ld returned 1 exit status
It seems as though I should probably consider getting external .jar/.zip
dependencies 'gcj-ized' to already have appropriate shared libraries to
link against. Does anyone else run into this problem using gcj?
I've tried the following in automake, but the libtool invocation of gcj
never puts the jar file on the command line needed to produce the shared
library libbytecode.so, resulting in a fairly useless shared library at
that.
lib_LTLIBRARIES = libcptools.la
if USE_GNUBYTECODE
lib_LTLIBRARIES += libbytecode.la
libbytecode_la_LINK = $(GCJLINK) $(BYTECODE_JAR)
libbytecode_la_SOURCES =
endif
When a .jar file contains classes referencing shared libraries to
implement native methods, is anything else required to properly gcj-ify
the .jar file other than what I've given above? Hopefully not, how
would one ever know without going through a great deal of trouble?
Assuming an external library dependency is compiled with gcj already and
installed, what is the proper way to link against it to produce an
executable? Answers in terms of command line and/or automake
appreciated.
Brian
-- 
Brian Jones <cbj@gnu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20050124/5667cd2f/attachment.sig>