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@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@gmail.com <mailto:dreamnext@gmail.com> (<dreamnext@gmail.com <mailto:dreamnext@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@gmail.com <mailto:dreamnext@gmail.com> (<dreamnext@gmail.com <mailto:dreamnext@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@gmail.com <mailto:dreamnext@gmail.com> (<dreamnext@gmail.com <mailto:dreamnext@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Attachment:
signature.asc
Description: OpenPGP digital signature