Pavel,
It works fine for me on Linux both with --disable-gcj and with gcj
support enabled.
Does your config.h have the symbol HAVE_GCJ_SUPPORT defined or not?
I assume not, but if it does, try reconfiguring with --disable-gcj.
Ideally, I don't want to compile and link eh.c if it's not defined.
However, I don't have to time to muck with automake/libtool for hours
to figure out how to do that. (Testing one simple change to an .am
file takes four minutes edit-compile-test time, and I don't have that
time. (*)
What I did is to pull the L_eh section out of libgcc2.c and stick it
in eh.c. I believe that even if you link with eh.o, this should
override all symbols in it, so there shouldn't be multiply defined
symbols --- at least there aren't any for me. I don't know. Maybe
the gcc driver you're using (or the way automake/libtool invokes it?)
uses different switches to the linker. Who knows.
I agree with you that it's weird that gcc/libtool/automake/whoever
tries to link with libgcc.a, which I thought only goes with executables
and not with shared libraries.
Note that my eh.c is from a more recent version of libgcc2.c than
any egcs release, but that shouldn't matter.
Let me know if you find anything. I think a quick fix may be to
wrap eh.c in #ifdef HAVE_GCJ_SUPPORT(?), but ideally I want it and
the other files in gcj/ out of the compilation.
Could you try that?
- Godmar
(*) Nor do I have the inclination to dig into it. I just wish
libtool died quickly, but once a project is part of "GNU", it'll stick
around forever. This would also free up resources since people like
Alexandre could focus on more useful and promising projects.
>
> Hello, Godmar and Libtool gurus!
>
> > I implemented some experimental facilities for supporting gcj-compiled
> > code in kaffe. You can precompile both kaffe's class libraries and
> > your application in this way, yet at the same time dynamically load
> > code that is translated. Currently, this only works for the x86 in a
> > shared library setting. I tested on Linux, FreeBSD/ELF should work
> > too.
>
> I'm affraid that your changes break compilation for those who don't use
> gcj.
>
> I'm using RedHat 6.1 for i386, which means egcs-1.1.2, binutils-2.9.1.0.23
> and glibc-2.1.2. Just in case, the kernel is linux-2.3.29. I also have the
> latest CVS versions of autoconf, automake and libtool, but I didn't run
> them. Moreover, I know that no files from the Kaffe CVS haven't been
> modified locally, which means that I'm using the "official" Makefile.in's
> and other stuff.
>
> Kaffe is the tatest from CVS.
> I don't give any arguments to "configure" and "make". When linking
> libkaffevm I'm getting the following:
>
> /bin/sh ../../libtool --mode=link gcc -g -O2 -Wall -Wstrict-prototypes
> -o libkaffevm.la -rpath /usr/local/lib -export-dynamic -release 1.0.5
> gc-mem.lo md.lo baseClasses.lo classMethod.lo classPool.lo methodCache.lo
> code-analyse.lo code.lo constants.lo debug.lo exception.lo external.lo
> findInJar.lo fp.lo gc.lo hashtab.lo inflate.lo itypes.lo jar.lo jni.lo
> locks.lo lookup.lo object.lo readClass.lo sha-1.lo soft.lo stackTrace.lo
> stats.lo string.lo support.lo thread.lo utf8const.lo gcFuncs.lo gcRefs.lo
> verify.lo ../../libltdl/libltdlc.la jit3/libengine.la gcj/libgcj.la
> systems/unix-jthreads/libkthread.la -lm -L/usr/local/lib
> -R/usr/local/lib
> mkdir .libs
> rm -fr .libs/libkaffevm.la .libs/libkaffevm.* .libs/libkaffevm-1.0.5.*
>
> *** Warning: inter-library dependencies are not known to be supported.
> *** All declared inter-library dependencies are being dropped.
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
> (cd . && ln -s gc-mem.lo gc-mem.o)
> (cd . && ln -s md.lo md.o)
> [... more similar stuff ...]
> gcc -shared gc-mem.lo md.lo baseClasses.lo classMethod.lo classPool.lo
> methodCache.lo code-analyse.lo code.lo constants.lo debug.lo exception.lo
> external.lo findInJar.lo fp.lo gc.lo hashtab.lo inflate.lo itypes.lo
> jar.lo jni.lo locks.lo lookup.lo object.lo readClass.lo sha-1.lo soft.lo
> stackTrace.lo stats.lo string.lo support.lo thread.lo utf8const.lo
> gcFuncs.lo gcRefs.lo verify.lo -Wl,--whole-archive
> ../../libltdl/.libs/libltdlc.al jit3/.libs/libengine.al
> gcj/.libs/libgcj.al systems/unix-jthreads/.libs/libkthread.al
> -Wl,--no-whole-archive -Wl,-soname -Wl,libkaffevm-1.0.5.so -o
> .libs/libkaffevm-1.0.5.so
> /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/libgcc.a(_eh.o): In
> function `__default_terminate':
> /usr/src/bs/BUILD/egcs-1.1.2/obj-i386-linux/gcc/../../gcc/libgcc2.c(.text+0x0):
>multiple
> definition of `__default_terminate'
> gcj/.libs/libgcj.al(eh.lo):/usr/local/src/kaffe/kaffe/kaffevm/gcj/eh.c:33: first
> defined here
> /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/libgcc.a(_eh.o): In
> function `__default_terminate':
> /usr/src/bs/BUILD/egcs-1.1.2/obj-i386-linux/gcc/../../gcc/libgcc2.c(.data+0x4):
>multiple
> definition of `__terminate_func'
> [... more errors follow ...]
>
> It looks like that certain functions from libgcc.a are redefined in the
> Kaffe code that is meant to support GCJ.
> It is also strange that libtool doesn't know about inter-library
> dependencies on GNU/Linux. Just in case, that's how libtool is configured:
>
> [proski@cambridge kaffe]$ ./libtool --features
> host: i586-pc-linux-gnu
> enable shared libraries
> disable static libraries
>
> Also it's very strange that ld tries to put some code from libgcc2.a
> (static library) to shared library libkaffevm-1.0.5.so
>
> Pavel Roskin
>
