Apache OpenOffice (AOO) Bugzilla – Issue 73328
building vanilla with java-gcj-compat
Last modified: 2013-02-07 21:58:20 UTC
GNU/Linux SPARC building m199 vanilla upstream on Debian/sid with java-gcj-compat-dev - build fails in testtools regcomp -register -br ../../unxlngs.pro/misc/bridgetest/bootstrap.rdb -r ../../unxlngs.pro/lib/uno_services.rdb -c \ file:///home/jim/vanilla/testtools/source/bridgetest/../../unxlngs.pro/class/testComponent.jar \ -env:URE_INTERNAL_JAVA_DIR=file:///home/jim/vanilla/solver/680/unxlngs.pro/bin using loader com.sun.star.loader.Java2 file:///home/jim/vanilla/testtools/source/bridgetest/../../unxlngs.pro/class/testComponent.jar [Java framework]sunjavaplugin.soJava runtime library: file:///usr/lib/../lib/libgcj.so.7 does not export symbol JNI_CreateJavaVM ! register component 'file:///home/jim/vanilla/testtools/source/bridgetest/../../unxlngs.pro/class/testComponent.jar' in registry '../../unxlngs.pro/lib/uno_services.rdb' failed! error (CannotRegisterImplementationException): Could not create Java implementation loader dmake: Error code 1, while making '../../unxlngs.pro/lib/uno_services.rdb' dmake: '../../unxlngs.pro/lib/uno_services.rdb' removed. '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making home/jim/vanilla/testtools/source/bridgetest jim@sun:~/vanilla/testtools$ Some info: jim@sun:~/vanilla/testtools$ cd ~ && java GetJVMInfo java.version= 1.4.2 java.vendor= Free Software Foundation, Inc. java.home= /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre gnu.classpath.home=/usr gnu.classpath.home.url=file:///usr/lib/../lib javax.accessibility.assistive_technologies=null jim@sun:~$ jim@sun:~/vanilla$ java -version java version "1.4.2" gij (GNU libgcj) version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20) jim@sun:~/vanilla$ javac -version Eclipse Java Compiler v_677_R32x, 3.2.1 release, Copyright IBM Corp 2000, 2006. All rights reserved. configured --with-jdk-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0 jim@sun:/usr$ find -name libjvm.so ... ./lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/server/libjvm.so ./lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/client/libjvm.so ./lib/gcj-4.1/libjvm.so jim@sun:/usr$ set | grep gcj AWTLIB='-ljawt -lgcj' JAVACOMPILER=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/bin/javac JAVADOC=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/bin/javadoc JAVAINTERPRETER=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/bin/java JAVA_HOME=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0 JDK=gcj LD_LIBRARY_PATH=.:/home/jim/vanilla/solenv/unxlngs.pro/lib: /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc:: /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/client: /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/native_threads: ../lib:/home/jim/vanilla/solver/680/unxlngs.pro/lib: ... SOLARLIB=' -L../lib -L/home/jim/vanilla/solenv/unxlngs/lib -L/home/jim/vanilla/solver/680/unxlngs.pro/lib -L/home/jim/vanilla/solenv/unxlngs/lib -L/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/lib -L/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc -L/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/client -L/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/native_threads -L/usr/lib' jim@sun:/usr$ Index: jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx =================================================================== RCS file: /cvs/udk/jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx,v retrieving revision 1.13 diff -u -r1.13 gnujre.cxx --- jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx 22 Nov 2006 11:27:46 -0000 1.13 +++ jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx 10 Jan 2007 09:22:51 -0000 @@ -68,6 +68,7 @@ static char const* ar[]= { "/lib/" JFW_PLUGIN_ARCH "/client/libjvm.so", "/gcj-4.1.1/libjvm.so", + "/gcj-4.1/libjvm.so", "/libgcj.so.7", "/libgcj.so.6" }; The patch fixes it, but is it the right way?
sparcmoz: it is
thanks
reassign
.
constantly patching that file to add an infinite no of libs isn't really desirable if avoidable. I wonder why it all didn't "just work", with libjvm.so being found first, i.e "/lib/" JFW_PLUGIN_ARCH "/client/libjvm.so" with JFW_PLUGIN_ARCH being sparc in this case just getting added on to /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre from java.home and getting found that way
@cmc: so it appears it is not found by JFW_PLUGIN_ARCH because it is in sparc/server or sparc/client in this case. This is in Debian/unstable. jim@sun:/usr$ find -name libjvm.so ... ./lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/server/libjvm.so ./lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/client/libjvm.so ./lib/gcj-4.1/libjvm.so vendorbase.hxx //Used by subclasses of VendorBase to build paths to Java runtime 049 #if defined UNX 050 #if defined SPARC 051 #define JFW_PLUGIN_ARCH "sparc"
more information: jim@sun:/usr$ ls -la lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/server/libjvm.so lrwxrwxrwx 1 root root 35 Jan 6 06:24 lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/server/libjvm.so -> ../../../../../../gcj-4.1/libjvm.so jim@sun:/usr$ ls -la lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/client/libjvm.so lrwxrwxrwx 1 root root 35 Jan 6 06:24 lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/client/libjvm.so -> ../../../../../../gcj-4.1/libjvm.so jim@sun:/usr$ So it is a symbolic link - could that be reason it does not work?
Being a link should be ok, and that's the path I'd expect it to look into, the /lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/sparc/client/libjvm.so i.e. /lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre + lib/JFW_PLUGIN_ARCH/client/libjvm.so Could you rebuild with s/regcomp/strace -f regcomp and attach the output of strace to see what libjvm opening attempts are used
Created attachment 42738 [details] @cmc: strace log for your comment thanks
I know this is not supported, but just for the record, another variation using gcc4.3 (Experimental) and --with-jdk-home=/usr/local/4.3 jim@sun:~/vanilla$ find /usr/local/4.3 -name libjvm.so /usr/local/4.3/lib/gcj-4.3.0/libjvm.so Therefore: "/lib/" JFW_PLUGIN_ARCH "/client/libjvm.so", + "/lib/gcj-4.3.0/libjvm.so",
Jim? What is the status?
The last important comment was this one: <quote> ------- Additional comments from cmc Wed Jan 10 11:54:28 +0000 2007 ------- constantly patching that file to add an infinite no of libs isn't really desirable if avoidable. </quote> I think that "constantly patching" is still required. I have no idea what to do.
Move target