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, dreamn...@gmail.com (<dreamn...@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, dreamn...@gmail.com (< > dreamn...@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
