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