From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220 Description of problem: OpenOffice.org2's build time java stuff works fine with gcj, until friday feb 11th that is. Spec and source for OOo2 remained unchanged while this error has materialized Exception in thread "main" java.lang.AbstractMethodError: normalize ()V at _Jv_Linker.make_vtable(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0) at _Jv_Linker.wait_for_state(java.lang.Class, int) (/usr/lib/libgcj_fc4.so.6.0.0) at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj_fc4.so.6.0.0) at _Jv_Linker.resolve_pool_entry(java.lang.Class, int) (/usr/lib/libgcj_fc4.so.6.0.0) at com.sun.star.help.HelpCompiler.compile() (Unknown Source) Version-Release number of selected component (if applicable): libgcj-3.4.3-19 How reproducible: Always Steps to Reproduce: 1. If it's not already a known problem I can try and isolate a smaller test case. Additional info:
Can you get exact package versions where it worked and where it doesn't? If you are using glibc-2.3.4-{7,8,9}, don't. Between libgcj-3.4.3-18 and -19 there were certainly no changes that would matter for this.
Created attachment 111048 [details] testcase This seems to reproduce it.
OOo2 has to use libgcj4, so perhaps my problem arises out of a libgcj issue between gcc4-4.0.0-0.22 -> gcc4-4.0.0-0.23, I'll downgrade my own version and give that theory a test.
That seems to be the problem alright.
Doesn't seem to be gcc4 nor -0.22 -> 0.23 specific: $ mkdir -p /tmp/gcj4xx $ cd /tmp/gcj44xx; rpm2cpio /mnt/redhat/beehive/comps/dist/fc4/gcc4/4.0.0-0.22/i386/libgcj4-4.0.0-0.22.i386.rpm; cd - $ CLASSPATH=jaxp.jar:parser.jar:xt.jar:. gij whyme Exception in thread "main" java.lang.AbstractMethodError at _Jv_MakeVTable(java.lang.Class) (/usr/lib/libgcj.so.5.0.0) at _Jv_PrepareClass(java.lang.Class) (/usr/lib/libgcj.so.5.0.0) at _Jv_WaitForState(java.lang.Class, int) (/usr/lib/libgcj.so.5.0.0) at java.lang.VMClassLoader.linkClass0(java.lang.Class) (/usr/lib/libgcj.so.5.0.0) at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.5.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.5.0.0) at _Jv_ResolvePoolEntry(java.lang.Class, int) (/usr/lib/libgcj.so.5.0.0) at whyme.main(java.lang.String[]) (Unknown Source) $ CLASSPATH=jaxp.jar:parser.jar:xt.jar:. gij4 whyme Exception in thread "main" java.lang.AbstractMethodError: normalize ()V at _Jv_Linker.make_vtable(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0) at _Jv_Linker.wait_for_state(java.lang.Class, int) (/usr/lib/libgcj_fc4.so.6.0.0) at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj_fc4.so.6.0.0) at _Jv_Linker.resolve_pool_entry(java.lang.Class, int) (/usr/lib/libgcj_fc4.so.6.0.0) at whyme.main(java.lang.String[]) (Unknown Source) $ LD_PRELOAD=/tmp/gcj4xx/usr/lib/libgij_fc4.so.6:/usr/lib/libgcj_fc4.so.6 LD_LIBRARY_PATH=/tmp/gcj4xx/usr/lib CLASSPATH=jaxp.ja Exception in thread "main" java.lang.AbstractMethodError: normalize ()V at _Jv_Linker.make_vtable(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0) at _Jv_Linker.wait_for_state(java.lang.Class, int) (/usr/lib/libgcj_fc4.so.6.0.0) at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj_fc4.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj_fc4.so.6.0.0) at _Jv_Linker.resolve_pool_entry(java.lang.Class, int) (/usr/lib/libgcj_fc4.so.6.0.0) at whyme.main(java.lang.String[]) (Unknown Source) $ rpm -q libgcj libgcj4 libgcj-3.4.3-19 libgcj4-4.0.0-0.23 Which means it fails with all 3 versions.
FYI, this is _Jv_Linker::make_vtable called on com.sun.xml.tree.XmlDocument class. gdb doesn't work on gij, but it seems last klass in make_vtable loop to find the normalize ()V abstract class was com.sun.xml.tree.NodeBase.
I don't see this problem with cvs head, but that is simply because we've merged in GNU JAXP, so all the core xml-related parser classes are now built in to libgcj. So, this is may be just hiding the real bug. On the other hand, linking com.sun.xml.tree.XmlDocument definitely is working here; another explanation could be that we've updated org.xml.sax.
Ignore comment #7. I had a patch in my tree that disabled a check in this area, and I forgot that. When I back this out I can reproduce this bug. I'm looking into this
Ok, the bug here starts with the fact that the w3c, unfortunately, violated java binary compatibility rules and added a method to an interface. Right now libgcj includes a newer version of org.w3c.dom. Because it is directly in the library, this means that the version of Node in the library is picked up in preference to the one in parser.jar. com.sun.xml.tree.NodeBase implements Node, but does not override the new normalize() method. This is "ok" since this class is abstract, as is com.sun.xml.tree.ParentNode. However, com.sun.xml.tree.XmlDocument is not, and it inherits the abstract method, leading to a runtime link error. First, how does this work on proprietary JVMs? My understanding is that the only way to override org.w3c.dom is to find it via the "java.endorsed.dirs" feature... is this what OOo does? Fixing this in libgcj is kind of tricky. It involves splitting up the library into some components. It is possible, we've talked about it already a couple of times... Another approach would be to change this code in OOo so that it uses the current version of org.w3c.dom and friends.
Today I happened to run across a clarification to the JVMS that, inexplicably, I hadn't seen before. It seems we do not need to throw an AbstractMethodError during linking; instead, the error can be caught when the method is actually called. I checked in a patch to change this. With this patch the test case works for me.
Should be fixed in gcc4-4.0.0-0.28.