help needed with LibreOffice Java bridge on armhf

[Rene Engelhard]

Hi,

since LibreOffice 7.6 (which added some more tests which were manual
before to the automatic set) the testtools' bridge test fails:

https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A7.6.2-5&stamp=1698791231&raw=0

only on armhf. armel and arm64 just work.

it says

[build CHK] test
S=/<<PKGBUILDDIR>> && I=$S/instdir &&
W=$S/workdir && mkdir -p $W/Module/check/ && touch
$W/Module/check/test
S=/<<PKGBUILDDIR>> && I=$S/instdir &&
W=$S/workdir &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/progr
am:$I/program"   $I/program/uno.bin -s
com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject -env:LO_BUILD_LIB_DIR=file://$W/Link
Target/Library -env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb &&
LD_LIBRARY_PATH=${L
D_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.Ja
vaTestObject noCurrentContext
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=fil
e://$W/UnoApiTarget/bridgetest.rdb
two floats struct test failed
*** stack smashing detected ***: terminated
Aborted (core dumped)
make[3]: ***
[/<<PKGBUILDDIR>>/testtools/CustomTarget_uno_test.mk:32:
/<<PKGBUILDDIR>>/workdir/CustomTarget/testtools/uno_test.done] E
rror 134

(Even though one probably shouldn't do it I did try to build it

- without -fstack-protector-strong -> with just -fstack-protector: fails
the same way

- without -fstack-protector:


Fails in a different way:

touch /data/ssd/rene/libreoffice-7.6.2/workdir/Executable/uno.run
S=/data/ssd/rene/libreoffice-7.6.2 && I=$S/instdir && W=$S/workdir &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.JavaTestObject noCurrentContext
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb
two floats struct test failed
four floats struct test failed
### float does not match! failed
### double does not match! failed
struct comparison test failed
armhf doubles test failed
### float does not match! failed
### double does not match! failed
recursive test results failed
remote multi failed: 0 != 6.38084e-314
standard test failed
exception occurred: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1275

> error: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1275
> dying...make: ***
[/data/ssd/rene/libreoffice-7.6.2/testtools/CustomTarget_uno_test.mk:32:
/data/ssd/rene/libreoffice-7.6.2/workdir/CustomTarget/testtools/uno_test.done]
Error 1

So might it be the same failure mode as ppc64/s390x?

See the discussion upstream in
https://lists.freedesktop.org/archives/libreoffice/2023-September/thread.html:
"new bridgetest failures in 7.6 on ppc64le "

(while mentioning ppc64el initially s390x is affected, too)

and continued in October


https://lists.freedesktop.org/archives/libreoffice/2023-October/thread.html

especially
https://lists.freedesktop.org/archives/libreoffice/2023-October/091058.html
and

https://lists.freedesktop.org/archives/libreoffice/2023-October/091059.html


after which unfortunately noting important happened. (And I don't see a
patch either at Fedora git nor submitted upstream to fix this.)

This is probably architecture-specific since the other architectures
*do* work (except ppc64el and s390x).


Can you have a look at it?

(The workaround would be --without-java which I verified to work on my
rpi4, but this opens a can of worms. Not only disabling some (built-in)
features like the Report Builder but especially since there is
Java-based extensions (_all!) which then get into trouble
dependency-wise/LO will be blocked from migrating to testing maybe...)

Regards,

Rene

[Rene Engelhard]

Hi,

Am 01.11.23 um 20:42 schrieb Rene Engelhard:

> (The workaround would be --without-java which I verified to work on my
> rpi4, but this opens a can of worms. Not only disabling some (built-in)
> features like the Report Builder but especially since there is
> Java-based extensions (_all!) which then get into trouble
> dependency-wise/LO will be blocked from migrating to testing maybe...)

I needed to do that now :(. It's live now in sid.

It now also makes natbrailles autopkgtest fail[1] since that one of
course wants ure-java which is Out-of-sync and probably should be
decrufted somewhen:

$ rmadison -s unstable ure-java
ure-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
ure-java | 4:7.6.4~rc1-1 | unstable | amd64, arm64, armel, i386

Regards,

Rene