I get the following build failure on m68k building gcc 4.2. I know this PR doesn't contain terribly much information but hopefully the problem is obvious; if not, I'll try to find out the information you need. /build/buildd/gcc-snapshot-20060508/build/./gcc/xgcc -shared-libgcc -B/build/buildd/gcc-snapshot-20060508/build/./gcc -nostdinc++ -L/build/buildd/gcc-snapshot-20060508/build/m68k-linux-gnu/libstdc++-v3/src -L/build/buildd/gcc-snapshot-20060508/build/m68k-linux-gnu/libstdc++-v3/src/.libs -B/usr/lib/gcc-snapshot/m68k-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/m68k-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/m68k-linux-gnu/include -isystem /usr/lib/gcc-snapshot/m68k-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libjava -I./include -I./gcj -I../../../src/libjava -Iinclude -I../../../src/libjava/include -I../../../src/libjava/classpath/include -Iclasspath/include -I../../../src/libjava/classpath/native/fdlibm -I../../../src/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../src/libjava/libltdl -I../../../src/libjava/libltdl -I../../../src/libjava/.././libjava/../gcc -I../../../src/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/usr/lib/gcc-snapshot\" -DLIBDIR=\"/usr/lib/gcc-snapshot/lib\" -DJAVA_HOME=\"/usr/lib/gcc-snapshot/jre\" -DBOOT_CLASS_PATH=\"/usr/lib/gcc-snapshot/jre/lib/rt.jar\" -DJAVA_EXT_DIRS=\"/usr/lib/gcc-snapshot/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/usr/lib/gcc-snapshot/share/java/gcj-endorsed\" -DLIBGCJ_DEFAULT_DATABASE=\"/usr/lib/gcc-snapshot/lib/gcj-4.2.0/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.2.0/classmap.db\" -DTOOLEXECLIBDIR=\"/usr/lib/gcc-snapshot/lib\" -g -O2 -D_GNU_SOURCE -MT link.lo -MD -MP -MF .deps/link.Tpo -c ../../../src/libjava/link.cc -fPIC -DPIC -o .libs/link.o ../../../src/libjava/link.cc:985: error: 'ffi_closure' does not name a type ../../../src/libjava/link.cc: In static member function 'static void* _Jv_Linker::create_error_method(_Jv_Utf8Const*)': ../../../src/libjava/link.cc:1006: error: 'struct method_closure' has no member named 'closure' ../../../src/libjava/link.cc:1009: error: 'ffi_prep_closure' was not declared in this scope ../../../src/libjava/link.cc:1010: error: 'struct method_closure' has no member named 'closure' ../../../src/libjava/link.cc:1020: warning: control reaches end of non-void function make[5]: *** [link.lo] Error 1 make[5]: Leaving directory `/build/buildd/gcc-snapshot-20060508/build/m68k-linux-gnu/libjava' make[4]: *** [all-recursive] Error 1
Based on build logs, this has been there at least since 20060419 (and possibly longer).
I'm CCing Andreas Schwab since he apparently ported ffi to m68k. I noticed that the part of the code that produces the error is within an ifdef USE_LIBFFI, so possibly disabling ffi on m68k would allow it to compile. But maybe the real fix would be to update ffi on m68k or something. Maybe Andreas can take a look and/or comment.
(In reply to comment #2) > I'm CCing Andreas Schwab since he apparently ported ffi to m68k. I noticed > that the part of the code that produces the error is within an ifdef > USE_LIBFFI, so possibly disabling ffi on m68k would allow it to compile. But > maybe the real fix would be to update ffi on m68k or something. Maybe Andreas > can take a look and/or comment. libffi should work on m68k. It might be closures have not been ported to m68k which means INTERPRETER should be false. (This is all from memory).
Only the error reporting needs support for closures, the other use of libffi in libgcj should work fine as long as libffi works, I think.
It looks to me that the code in link.cc is testing the wrong define. It is testing USE_LIBFFI, but that is defined if any part of libffi is in use. Instead it should be testing INTERPRETER -- ideally we'd add a new macro indicating whether libffi has the closure API ported, as INTERPRETER catches a bit too much. Could you try changing USE_LIBFFI to INTERPRETER in link.cc? There are a few places to change. If that fixes the problem for you, we can check it in.
ffitarget.h already provides a macro for closure support: FFI_CLOSURES. Does this patch makes sense? Index: link.cc =================================================================== --- link.cc (revision 114359) +++ link.cc (working copy) @@ -788,7 +788,7 @@ _Jv_ThrowNoSuchMethodError () throw new java::lang::NoSuchMethodError; } -#ifdef USE_LIBFFI +#if defined USE_LIBFFI && FFI_CLOSURES // A function whose invocation is prepared using libffi. It gets called // whenever a static method of a missing class is invoked. The data argument // holds a reference to a String denoting the missing class. @@ -974,7 +974,7 @@ _Jv_Linker::find_iindex (jclass *ifaces, return i; } -#ifdef USE_LIBFFI +#if defined USE_LIBFFI && FFI_CLOSURES // We use a structure of this type to store the closure that // represents a missing method. struct method_closure @@ -1027,7 +1027,7 @@ _Jv_Linker::create_error_method (_Jv_Utf // of the missing class then. return (void *) _Jv_ThrowNoClassDefFoundError; } -#endif // USE_LIBFFI +#endif // USE_LIBFFI && FFI_CLOSURES // Functions for indirect dispatch (symbolic virtual binding) support.
Thanks, Andreas. The file compiles with this patch. But now it fails a little bit later: gnu/java/net/natPlainDatagramSocketImpl.cc: In member function 'virtual void gnu::java::net::PlainDatagramSocketImpl::receive(java::net::DatagramPacket*)': gnu/java/net/natPlainDatagramSocketImpl.cc:351: error: impossible constraint in 'asm' make[1]: *** [gnu/java/net/natPlainDatagramSocketImpl.lo] Error 1 any idea?
I don't see that here. You are probably using the wrong glibc headers. There is no asm in FD_ZERO for m68k.
Andreas -- yes, that patch looks good to me. Please check it in. Thanks!
(In reply to comment #8) > I don't see that here. You are probably using the wrong glibc headers. There > is no asm in FD_ZERO for m68k. For some reason, /usr/include got included even though I'm cross-compiling. Anyway, I removed that and it's building. I'll let you know if there's another problem later on but so far it looks good. Thanks for your patch!
It has built successfully.
Subject: Bug 27860 Author: schwab Date: Mon Jun 5 21:21:05 2006 New Revision: 114411 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114411 Log: PR libgcj/27860 * link.cc: Check for closure support in libffi with FFI_CLOSURES. Modified: trunk/libjava/ChangeLog trunk/libjava/link.cc
Fixed.