Apache OpenOffice (AOO) Bugzilla – Issue 71435
ooe680-m2 incompatible with gcj 4.2/4.3
Last modified: 2007-01-09 11:36:40 UTC
Building ooe680-m2 with gcj 4.2 (or higher) results in: using loader com.sun.star.loader.Java2 [Java framework]sunjavaplugin.soJava runtime library: file:///usr/lib/libgcj.so.8 does not export symbol JNI_CreateJavaVM ! register component 'file:///usr/src/ark/BUILD/ooo-build/build/ooe680-m2/testtools/source/bridgetest/../../unxlngi6.pro/class/testComponent.jar' in registry '../../unxlngi6.pro/lib/uno_services.rdb' failed! error (CannotRegisterImplementationException): Could not create Java implementation loader The gcj guys have decided to move the JNI_CreateJavaVM symbol from libgcj to libjvm to be more compatible with the non-free Java implementations; and to make matters worse, libjvm.so is outside the normal library search path -- it resides in /usr/lib/gcj-4.2.0 (replace 4.2.0 with any gcc version after 4.2.0 that will be released). There's some code to handle this in jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx -- but it works only for listed gcc versions -- the search paths (including the gcj-VERSION path bit) are hardcoded: static char const* ar[]= { "/lib/" JFW_PLUGIN_ARCH "/client/libjvm.so", "/gcj-4.1.1/libjvm.so", "/gcj-4.1/libjvm.so", "/libgcj.so.8", "/libgcj.so.70", "/libgcj.so.7", "/libgcj.so.6" }; I'll add a patch that adds support for 4.2.0 and 4.3-svn, but I think a better fix would be to add something more along the lines of "/gcj-" GCJ_VERSION "/libjvm.so" along with a configure check for the gcj version in use. This would still break using a 4.2.0-compiled OOo with gij 4.2.1 -- so a real (runtime) check would be greatly preferrable.
Created attachment 40504 [details] primitive fix -- adding 4.2.0 and 4.3.0 to places to look in
With the introduction of libjvm to gcc my position would be that gcj and so on should be treated the same as any java and from configure use --with-jdk-home set to a hierarchy that implements a sun-alike environment, e.g. under fedora java-gcj-compat implements a set of links that does this, I bet your distro also has something like this ?
Not currently, but we're planning to add something like it anyway (in fact the only reason it isn't done yet is that our Java knowledge can be summed up as "looks pretty much like C++" ;) ), so I wouldn't be opposed to just assuming it's there... Might confuse ppl who are building their OS from scratch, but they're typically the ones who would know how to set up the correct symlinks anyway.
->Jochen, could you please take care of this? Putting my self on CC:, just in case ;-)
JL->CMC: Could you handle this on one of your CWS?
As bero says, we'd have to chase every release if we want to hold to searching in /lib/gcc-foo/libjvm.so and the libjvm was introduced to be sun-alike, so I reckon we shouldn't track /lib/gcc-foo but require a sun-alike set of links as done by debian and redhat and so on. So alternatively I suggest to instead add something to configure.in that detects if the gcj is an old one that has the jvm inside libgcj and do what we did back then, or a new one that has it in libjvm and in the new case fall into the existing sun test at configure time which will say something like "please use --with-jdk-home to set the location of libjvm"
Created attachment 40891 [details] patch to warn builder the same was for new gcj as it does for sun java
committed my proposal to detect this scenario to config_office in cmcfixes29
i.e. for gcj >= 4.2.0 we do the same test as we do with sun java for JAVA_HOME and so forth because it has the same sort of libjvm.so as sun java does and gets treated the same in basically requiring a sunalike hierarchy to be provided, which is the gcj guys intent in introducing that .so. Situation unchanged for gcj < 4.2.0 where the libgcj.so is the jvm providing .so
.
seen in master