We'd like to continue the production of the 32-bit deb packages

Michael Weghorn m.weghorn at posteo.de
Wed Aug 7 19:44:23 UTC 2019


Is there more output for the failing unit test that indicates what might
be going wrong? You can e.g. also paste larger output at
http://paste.debian.net/ or some similar service.

As a workaround, you can also try building LibreOffice without running
the unit tests for now, by using 'make build-nocheck' instead of the
plain 'make' command.

On 07/08/2019 00.12, dreamnext at gmail.com wrote:
> Well, I did a third compile try, but it failed again.
> 
> This time first I did a clean up:
> 
> -------
> make clean
> ------
> 
> Then I did a ./configure, passing CFLAGS and CFLAGSXX as:
> 
> -------
> ./configure CFLAGS='-mfpmath=sse -msse2' CFLAGSCXX='-mfpmath=sse -msse2'
> --with-jdk-home=/usr/lib/jvm/default-java
> -------
> 
> ./configure is in fact reading those flags, as can be seen on the
> relevant part of its output:
> 
> -----------------------
> checking whether to use link-time optimization... no
> checking for explicit AFLAGS... no
> checking for explicit CFLAGS... -mfpmath=sse -msse2
> checking for explicit CXXFLAGS... -mfpmath=sse -msse2
> checking for explicit OBJCFLAGS... no
> checking for explicit OBJCXXFLAGS... no
> checking for explicit LDFLAGS... no
> -------------------------
> 
> Then I did a make, again passing the CFLAGS(XX) as parameters:
> 
> ----------------
> make CLAGS='-mfpmath=sse -msse2' CFLAGSCXX='-mfpmath=sse -msse2'
> ----------------
> 
> But it failed again at the CpuunitTest stuff, although the error message
> is a bit different from the previous ones:
> 
> -------------------------
> Failures !!!
> Run: 52   Failure total: 1   Failures: 1   Errors: 0
> 
> Error: a unit test failed, please do one of:
> 
> make CppunitTest_sw_layoutwriter CPPUNITTRACE="gdb --args"
>     # for interactive debugging on Linux
> make CppunitTest_sw_layoutwriter VALGRIND=memcheck
>     # for memory checking
> make CppunitTest_sw_layoutwriter DEBUGCPPUNIT=TRUE
>     # for exception catching
> 
> You can limit the execution to just one particular test by:
> 
> make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
> 
> /home/linux/libreoffice/libreoffice/solenv/gbuild/CppunitTest.mk:113:
> recipe for target
> '/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sw_layoutwriter.test'
> failed
> make[1]: ***
> [/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sw_layoutwriter.test]
> Error 1
> make[1]: *** Waiting for unfinished jobs....
> Makefile:282: recipe for target 'build' failed
> make: *** [build] Error 2
> -----------------------------
> 
> So... what else could be done to reach the goal of building LIbreOffice
> 32-bit?
> 
> Thanks again in advance.
> 
> El lun., 5 ago. 2019 a las 16:40, dreamnext at gmail.com
> <mailto:dreamnext at gmail.com> (<dreamnext at gmail.com
> <mailto:dreamnext at gmail.com>>) escribió:
> 
> 
>     Well, based on the info that Stephan kindly passed, I tried 'make'
>     with the following parameters:
> 
>     make ENVCFLAGS="-mfpmath=sse -msse2" ENVCFLAGSCXX="-mfpmath=sse -msse2"
> 
>     However, it threw the same error as before.
> 
>     I intentionally did not type 'make clean' beforehand because:
> 
>     1) I'm assumming that those additional flags would be applied in the
>     code that fails to compile. I *think* that if it didn't not work
>     again, that would mean that the issue is something else?
>     2) I'm willing to do a 'make clean' if my above assumption is
>     incorrect, even if that means another 7 hours of hard work for my
>     poor computer. However, as I stated before, for this scenario I'm
>     following the instructions from
> 
>     https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/
> 
>     But I have no idea which version of LibreOffice I'm compiling. To be
>     worth all the extra efforts that a 'make clean' represents, I'd like
>     to be sure that I'm trying to compile LibreOffice 6.3.
> 
>     Is there a way to prove or instruct that LibreOffice 6.3 is the
>     selected one to compile?
> 
>     Best Regards and Thanks in advance.
> 
>     El lun., 5 ago. 2019 a las 9:53, dreamnext at gmail.com
>     <mailto:dreamnext at gmail.com> (<dreamnext at gmail.com
>     <mailto:dreamnext at gmail.com>>) escribió:
> 
>         Well, my first compile attempts had not been very good.
> 
>         I followed the instructions kindly provided by Michael Weghorn,
>         and downloaded and uncompress the source packages
>         libreoffice-6.3.0.3.tar.xz,
>         libreoffice-dictionaries-6.3.0.3.tar.xz,
>         libreoffice-help-6.3.0.3.tar.xz and
>         libreoffice-translations-6.3.0.3.tar.xz
> 
>         The first issue was that autogen requires the presence of
>         gstreamer1.0 AND of gstreamer0.10. gstreamer0.10 is deprecated,
>         but anyway I found and installed the required gstreamer0.10 deb
>         packages from elsewhere, but it still complained that they were
>         missing, so I added a --disable-gstreamer-0-10 parameter.
> 
>         Then a new error appeared:
> 
>         "configure: error: Wrong qmake for Qt5 found. Please specify the
>         root of your Qt5 installation by exporting QT5DIR before running
>         "configure".
>         Error running configure at ./autogen.sh line 302."
> 
>         However, the qt5-qmake and qt5-qmake-bin packages are installed
>         in my system!
> 
>         Since I was not able to stat compiling using Michael
>         instructions, I wondered what would happen if I followed instead
>         the steps recently published on the LibreOffice blog
>         (https://blog.documentfoundation.org/blog/2019/06/12/start-developing-libreoffice-download-the-source-code-and-build-on-linux/)
>         It was a blind choice, since I have no idea what LibreOffice
>         version would I get if compiled (is there a way to get an
>         specific version?), or how easy would be to generate deb
>         packages afterwards.
> 
>         In that set of instructions I changed:
> 
>         --with-lang=hu en-US
> 
>         to
> 
>         --with-lang=es en-US
> 
>         in order to try to obtain a LibreOffice in Spanish language, not
>         in Hungarian.
> 
>         I also removed the following lines:
> 
>         --with-referenced-git=/home/linuxosfelhasznalonev/libreoffice/core
>         --with-external-tar=/home/linuxosfelhasznalonev/libreoffice/core/external/tarballs
> 
> 
>         As they point to hard paths on the disk of the article author. I
>         tried to reproduce those paths to match my own by creating core,
>         external and tarballs directories, but it didn't work, so I
>         merely removed those two lines.
> 
>         This time it began compiling, but after A LOT of hours and more
>         of 40 GB used, the make command always stops at this error:
> 
> 
>         "Error: a unit test failed, please do one of:
>         make CppunitTest_sc_filters_test CPPUNITTRACE="gdb --args"
>             # for interactive debugging on Linux
>         make CppunitTest_sc_filters_test VALGRIND=memcheck
>             # for memory checking
>         make CppunitTest_sc_filters_test DEBUGCPPUNIT=TRUE
>             # for exception catching
>         You can limit the execution to just one particular test by:
>         make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
>         /home/linux/libreoffice/libreoffice/solenv/gbuild/CppunitTest.mk:113:
>         recipe for target
>         '/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sc_filters_test.test'
>         failed
>         make[1]: ***
>         [/home/linux/libreoffice/libreoffice/workdir/CppunitTest/sc_filters_test.test]
>         Error 1
>         Makefile:167: recipe for target 'CppunitTest_sc_filters_test' failed
>         make: *** [CppunitTest_sc_filters_test] Error 2"
> 
>         So, I'm kind of stuck in both procedures. Does somebody knows
>         how to solve on one or both?
> 
>         Thanks in advance
> 
>         El vie., 26 jul. 2019 a las 10:01, dreamnext at gmail.com
>         <mailto:dreamnext at gmail.com> (<dreamnext at gmail.com
>         <mailto:dreamnext at gmail.com>>) escribió:
> 
>             Hi! Greetings from the Escuelas Linux team. We are small
>             Linux distribution that can be downloaded from
>             https://sourceforge.net/projects/escuelaslinux/.
>             Some more references about our activity can be found by
>             doing an Internet search, or on own Facebook account,
>             escuelas.linux
> 
>             We still provide a 32-bit edition of our distro, because
>             among our users there are a lot of low-income public
>             schools, in which are still in use old computers with about
>             512 MB to a 1 GB of RAM. That amount of RAM would make
>             running a Linux 64-bit system awfully slow, so we have to
>             accommodate to the needs and possibilities of what is
>             available in poor areas, those in which even having an old
>             computer is still somehow a luxury.
> 
>             We perfectly understand that TDF releasing 32-bit Linux
>             LibreOffice packages was not worth anymore, given the small
>             amount of downloads. Certainly some of those downloads were
>             made by us, as we only required one download of a given
>             LibreOffice version to have it installed in our distro and
>             be used in hundreds of computers. A lot of those computers
>             could not even be traceable, since there are no Internet
>             connection in poor or remote schools. But we believe that
>             even if we reported who and where are those schools, that
>             would be still a small amount to be worth the effort and
>             resources required to match the bigger amounts of downloads
>             that seems to be receiving the LibreOffice 32-bit Windows
>             counterpart.
> 
>             Given that TDF ended the provision of Linux 32-bit
>             distribution neutral binaries, but not the 32-bit
>             compatibility, we would like to step up to produce by
>             ourselves the 32-bit distribution neutral deb packages from
>             LibreOffice 6.3 and up. We are not aware of other distros or
>             volunteers releasing the most recent LibreOffice version to
>             date (6.3) as 32-bit distribution independent binaries.
> 
>             Recently, the official LibreOffice Blog published
>             instructions about how to compile LibreOffice on Linux.
>             However, we’d like to be able not only to compile
>             LibreOffice, but we would like to learn how to be able to
>             produce by ourselves the same set of 32-bit
>             distribution-independent deb packages that were compressed
>             as a .tar.gz, that is, the LibreOffice binaries
>             (LibreOffice_?.?.?_Linux_x86-_deb.tar.gz), the translated
>             user interface (the
>             LibreOffice_?.?.?_Linux_x86-_deb_langpack_??.tar.gz) and the
>             offline help
>             (LibreOffice_?.?.?_Linux_x86-_deb_helppack_??.tar.gz). As
>             for the user interface and the offline packages, our main
>             focus would be Spanish language.
> 
>             On the download section is always available the following
>             source code packages:
>             libreoffice-?.?.?.?.tar.xz
>             libreoffice-dictionaries-?.?.?.?.tar.xz
>             libreoffice-help-?.?.?.?.tar.xz
>             libreoffice-translations-?.?.?.?.tar.xz
> 
>             But, given our inexperience, we don’t know how to use this
>             source packages to produce the same set of 32-bit deb
>             packages as were previously provided by TDF. Since
>             LibreOffice is distributed in a lot of languages, we guess
>             that the user interface and offline packages are not created
>             manually one by one by hand, some useful scripts could have
>             been created to automate as far as possible those tasks.
> 
>             So, we respectfully ask for some pointers and steps required
>             to reach this goal. In this way, we might be able to
>             continue the production of the 32-bit deb packages, freeing
>             TDF of that burden as planned but, at the same time, we
>             could provide those packages for the parties that could be
>             still interested in them. We could not be able to support
>             rpm-based binaries though, someone else would have to step
>             up if there's a need for that.
> 
>             Please let us know if this request of help is feasible for
>             the Developer(s) that are responsible of the LibreOffice
>             packaging.
> 
> 
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20190807/bb7a2711/attachment.sig>


More information about the LibreOffice mailing list