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