Apache OpenOffice (AOO) Bugzilla – Issue 109214
OpenBSD porting: regcomp cannot find some java libraries because of "non-standard" path
Last modified: 2017-05-20 11:35:15 UTC
In testtools/source/bridgetest: JavaVM: JNI_CreateJavaVM called _exit, caught by abort_handler in javavm.cxx [Java framework] sunjavaplugin.soCan not create JavaVirtualMachine, abort handler was called. --- Turning on LD_DEBUG reveals that it can find some java libraries because they are not in the shared library cache, and they are not in the configured search directories: /var/run/ld.so.hints: search directories: /usr/lib:/usr/X11R6/lib:/usr/local/lib --- This can be fixed by adding the following paths to LD_LIBRARY_PATH in unx.mk. I've attached a diff that has the modification. Currently this is only a hack that makes it work, so I think we have to come up with something else. The error itself with LD_DEBUG enabled: head /usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so obj /usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so has /usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so as head linking /usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so as dlopen()ed head [/usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so] examining: '/usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so' loading: libjvm.so required by /usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so dlopen: failed to open libjvm.so unload_shlib called on /usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so unload_shlib unloading on /usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so dlopen: /usr/local/jdk-1.5.0/jre/lib/amd64/libverify.so: done (failed). dlopen: loading: /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so head /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so obj /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so has /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so as head linking /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so as dlopen()ed head [/usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so] examining: '/usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so' loading: libverify.so required by /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so dlopen: failed to open libverify.so unload_shlib called on /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so unload_shlib unloading on /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so dlopen: /usr/local/jdk-1.5.0/jre/lib/amd64/libjava.so: done (failed). JavaVM: JNI_CreateJavaVM called _exit, caught by abort_handler in javavm.cxx [Java framework] sunjavaplugin.soCan not create JavaVirtualMachine, abort handler was called. doing dtors obj 0x20f609360 @0x210a202c0: [/home/pobj/openoffice-3.2.0/OOO320_m12/solver/320/unxobsd.pro/lib/sunjavaplugin.so] LD_LIBRARY_PATH=/home/pobj/openoffice-3.2.0/OOO320_m12/solver/320/unxobsd.pro/lib:/usr/local/jdk-1.5.0/jre/lib/amd64/server:/usr/local/jdk-1. 5.0/jre/lib/amd64:.
Created attachment 67791 [details] unx.mk
Ok that's not even enough because then packaging will fail because of the same issue, so it has to be set in the environment itself.
In an OOo installation set, openoffice.org/ure/bin/regcomp is a shell script that calls javaldx to extend LD_LIBRARY_PATH (because various JVMs have internal issues where a plain dlopen(libjvm.so) will lead to a VM where some part like AWT do not work) and only then calls the true regcomp.bin binary. In the build environment, however, regcomp is not the shell script but a duplication of regcomp.bin. I assume that the problems with the JVM on OpenBSD are such that javaldx setting LD_LIBRARY_PATH would work around them, and I assume that the problems you report are in a call to regcomp. Therefore, I would suggest to change cpputools to deliver the appropriate shell script as regcomp (and change all the calls to regcomp from within the build environment to tell javaldx to use the correct JVM, -env:UNO_JAVA_JFW_ENV_JREHOME=true -env:UNO_JAVA_JFW_ENV_CLASSPATH=true).
.
Reset assigne to the default "issues@openoffice.apache.org".