Bug 820554

It evidently works when run from %check. Could you try to run it in the same way, i.e.,

unset WITH_LANG
unset SOLAR_JAVA
JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY="1" SAL_USE_VCLPLUGIN="svp" build.pl

IIRC the smoketest is run headless during %check. I run it in Xsession or with exported DISPLAY. The failure I get is when it opens smoketestdoc.sxw, which is not run in headless.

its not headless vs non-headless, its gcj vs everything else. My understanding is that openjdk is going into RHEL-6.3 (right?) so I wonder if it makes sense to debug this down to find the flaw, which is likely in gcj itself, in the light of that.

OpenJDK is not available for ppc64/s390x. 

In the first place I want to make sure it's not a bug in LO, in the second place I'd like to be able to run smoketest/subsequenttests as it helps us during regression testing. Both tests run fine on x86. But I understand if that won't be possible because of gcj.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7ef203d2bf72f7d96fd10d1297af06e82550a1c4

and

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b3bf27cb56d661725ac3fcfb756562e0ad75564

required anyway, probably not the full story yet

bug 826609 is related somehow I bet

http://cgit.freedesktop.org/libreoffice/core/commit/?id=962c7209b6f8b708d0b9337cbe5072aa52cda1bb is likely another part of the puzzle

This is indeed only related to PPC64 in so far as there is only gcj and no OpenJDK there; the problem is related to gcj irrespective of architecture.  The problem is unrelated to running smoketest headless or not (and that %check succeeds is because it unsets SOLAR_JAVA for rhel<7, so skips the failing extension tests within smoketest).

What happens is the following:

* bridges/source/jni_uno/java/com/sun/star/bridges/jni_uno/JNI_info_holder.java (in java_uno.jar) calls NativeLibraryLoader to load libjava_uno.so (located in LO's ure/lib dir).

* jurt/com/sun/star/lib/util/NativeLibraryLoader.java first tries to load the lib via "loader.getResource(name)" (in getResource; the loader is the UnoClassLoader, at least because it explicitly includes java_uno.jar in its URL list, see the "TODO get rid of it here" in ridljar/source/unoloader/com/sun/star/lib/unoloader/UnoClassLoader.java).  For some reason, that succeeds with OpenJDK (at least verified with java-1.7.0-openjdk-1.7.0.9-2.3.3.fc17.1.x86_64) but not with gcj, where NativeLibraryLoader.getResource returns null, so that NativeLibraryLoader.loadLibrary tries "System.loadLibrary(libname)" as a last resort.

* What that "System.loadLibrary(libname)" effectively results in is a dlopen("libjava_uno.so") from cgj's libjvm.so.

* Due to <http://cgit.freedesktop.org/libreoffice/core/commit/?id=dda5eaa8c0ddfecaaf29e75f2412f7182b9c5744> "Use DT_RUNPATH over DT_RPATH" LO 3.4 soffice.bin (and uno.bin) have both RPATH and RUNPATH settings.  This causes the above dlopen to not consider the executable's RPATH (which is by design, as RUNPATH is also specified) nor RUNPATH.  Whether the latter is a bug or a feature is still not entirely clear to me, cf. <http://sourceware.org/ml/libc-help/2012-11/msg00000.html> "How executable's RPATH/RUNPATH affects .so's dlopen."

* With the change of LO's build system from dmake to GNU Make, the above commit is becoming irrelevant (in converted modules, unit tests always pick up libraries from solver, anyway) and only affects modules that have not yet been reverted.  Therefore, in LO 3.5.7 soffice.bin no longer has a RUNPATH (but uno.bin still has), and in LO 3.6.3 both soffice.bin and uno.bin no longer have a RUNPATH in addition to RPATH.

* This implies that at least starting with LO 3.6.3, the smoketest should also work with gcj, and thus on PPC64.  (I verified it by manually rebuilding soffice.bin and uno.bin with the above commit's --enable-new-dtags switches temporarily removed, and then successfully running the second step of the recipe in the original description.)  It also implies that various Java-related functionality in RHEL 6's LO 3.4 is broken when using gcj, irrespective of architecture (I updated the summary accordingly).

Irrespective of whether or not this is boils down to a glibc bug (and I hope to get that clarified soon, see the mailing list link above), a fix would be to revert the above commit (as it effectively only affects rebuilds, so is not needed in a from-scratch rpmbuild anyway).

grrr, law of unexpected side effects. Either way its fixable, so I'll set dev-ack+

Smoketest failed on ppc64.
libreoffice-4.0.4.2-8.el6.ppc64
java-1.5.0-gcj-1.5.0.0-29.1.el6.ppc64

[snip]
[Java framework] The JRE specified by the bootstrap variable UNO_JAVA_JFW_JREHOME  or  UNO_JAVA_JFW_ENV_JREHOME  could not be recognized. Check the values and make sure that you use a plug-in library that can recognize that JRE.
warn:legacy.osl:4455:5:/home/test/rpmbuild/BUILD/libreoffice-4.0.4.2/jvmfwk/source/framework.cxx:797: [Java framework] The JRE specified by the bootstrap variable UNO_JAVA_JFW_JREHOME  or  UNO_JAVA_JFW_ENV_JREHOME  could not be recognized. Check the values and make sure that you use a plug-in library that can recognize that JRE.
javaldx failed! 
Warning: failed to read path from javaldx

Exited with code '0'
smoketest.cxx:198:Assertion
Test name: N12_GLOBAL__N_14TestE::test
equality assertion failed
- Expected: 
- Actual  :  Extensions:services(Extension SmokeTestCommandEnvironment (impleme
nted in Java))

Failures !!!
Run: 1   Failure total: 1   Failures: 1   Errors: 0

Created attachment 794785 [details]
Full debug log

(In reply to Jiri Koten from comment #17)
Jiri, with what command line exactly did you execute the smoketest for libreoffice-4.0.4.2-8?

I ran 'make check' and after fail I reran with 'make smoketest.subsequentcheck'

You need to set the environment variable JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 (as is done in the---commented out---%check section of libreoffice.spec) to work around bug 1007803 when using LibreOffice with gcj and no $DISPLAY.

Confirmed the workaround, smoketest passed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1594.html