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