On Sat, 2023-08-19 at 09:06 +0200, Dan Horák wrote:
On Sat, 19 Aug 2023 06:52:28 -0000
"Mattia Verga" <mattia.verga(a)proton.me> wrote:
> Hello,
> while trying to upgrade LibreOffice to 7.6 version we (libreoffice-
> sig) are facing a build failure that happens only on ppc64le:
>
https://download.copr.fedorainfracloud.org/results/mattia/Libreoffice7.6t...
>
> As we have no C skills to try patching the code and we have also no
> real hardware to test the current LO functionality (the current
> version was built by excluding several failing tests) we are
> considering dropping ppc64le architecture from building [1].
> Is there anyone interested in using LO under ppc64le? Has anyone
> got any idea what the build failure may be caused from? (to me it
> looks like something related to boost libraries)
this looks like an "out of memory" situation (g++ has been killed), I
see it's using -j2, so I would try to reduce it to "serial" (-j1). I
will look closer after the weekend.
Hello,
I'm not officially part of the Fedora team or anything. I lurk on this
list because I run a ppc64le machine running Fedora with plenty of ram.
I agree, it looks very much like OOM. I've no idea what the copr build
nodes for ppc64le look like or how jobs are scheduled, but given they
built firefox as well, I would guess they have sufficient ram.
The build log comes with a nice command to execute the build locally,
which is helpful as I'm only vaguely familiar with Fedora's tooling for
this sort of thing. I ran
sudo dnf install copr-rpmbuild copr-distgit-client
(the first is suggested by copr's log, the latter is not but is
required apparently) then:
/usr/bin/copr-rpmbuild --verbose --drop-resultdir --task-url
https://copr.fedorainfracloud.org/backend/get-build-task/6299738-fedora-r...
--chroot fedora-rawhide-ppc64le
to execute the build on my machine. My build ran with -j32. I'm able to
compile the compilation unit yours fails on, although the build fails
further along in its unit tests:
[build CXX] toolkit/qa/cppunit/Dialog.cxx
[build CXX] toolkit/qa/cppunit/EventContainer.cxx
[build CXX] toolkit/qa/cppunit/UnitConversion.cxx
[build CXX] toolkit/qa/cppunit/a11y/AccessibleStatusBarTest.cxx
[build CXX] toolkit/qa/cppunit/a11y/XAccessibleComponentTester.cxx
two floats struct test failed
four floats struct test failed
[build CXX] toolkit/qa/cppunit/a11y/XAccessibleContextTester.cxx
standard test failed
exception occurred: error: test failed! at
/builddir/build/BUILD/libreoffice-
7.6.0.3/testtools/source/bridgetest/bridgetest.cxx:1272
error: error: test failed! at /builddir/build/BUILD/libreoffice-
7.6.0.3/testtools/source/bridgetest/bridgetest.cxx:1272
dying...make[1]: *** [/builddir/build/BUILD/libreoffice-
7.6.0.3/testtools/CustomTarget_uno_test.mk:32:
/builddir/build/BUILD/libreoffice-
7.6.0.3/workdir/CustomTarget/testtools/uno_test.done] Error 1
make[1]: *** Waiting for unfinished jobs....
/builddir/build/BUILD/libreoffice-
7.6.0.3/i18nlangtag/qa/cppunit/test_languagetag.cxx: In member function
'(anonymous namespace)::TestLanguageTag::testAllTags()':
/builddir/build/BUILD/libreoffice-
7.6.0.3/i18nlangtag/qa/cppunit/test_languagetag.cxx:48:6: note:
variable tracking size limit exceeded with '-fvar-tracking-
assignments', retrying without
48 | void TestLanguageTag::testAllTags()
| ^~~~~~~~~~~~~~~
make: *** [Makefile:289: build] Error 2
I can share the full log if it helps.
I'm not familiar with LO's source tree, but I'd guess this is now at
the point of working out what tests should be disabled. The build took
20GB ram at most, with other stuff open on my desktop including firefox
and email.
> Is there anyone interested in using LO under ppc64le?
I do actually use it sometimes yes, so thanks for your efforts getting
it to build so far! On the other hand I do understand that there's a
cost/benefit tradeoff to make and I was also anticipating that at some
point it would disappear in favour of a flatpak-based install (and
flathub does not have ppc64le builds afaik, so would disappear
completely for ppc64le).
--
Antony