We'd like to continue the production of the 32-bit deb packages
dreamnext at gmail.com
dreamnext at gmail.com
Thu Aug 8 15:36:17 UTC 2019
Thanks for you help. the 'make build-nocheck' did the trick of passing the
unit test, and it finishes successfully :-)
Now I'm on the stage of trying to build distributable deb files. As
suggested before, I added the following lines to autogen.input
--with-distro=LibreOfficeLinux
--enable-release-build
--with-package-format=deb
--disable-dependency-tracking
Next I added export QT5DIR="/usr/lib/i386-linux-gnu/qt5" because in my
system is not enough to have the qt5-make and qr5-make-bin packages
installed.
Then I Installed a bunch of packages that seems to be necessary. As they
seem to be KF5/QT5 related, I installed the suggested ones for kdenlive
development: https://community.kde.org/Kdenlive/Development/KF5, maybe some
were not necessary, but would be hard to know which ones.
sudo apt-get install build-essential pkg-config \
libavformat-dev libavdevice-dev frei0r-plugins-dev frei0r-plugins
libgtk2.0-dev libexif-dev \
libsdl2-dev libsox-dev libxml2-dev \
ladspa-sdk libcairo2-dev libswscale-dev qtscript5-dev libqt5svg5-dev \
libqt5opengl5-dev libepoxy-dev libeigen3-dev libfftw3-dev \
git yasm libtool automake autoconf libtool-bin libtheora-bin
libtheora-dev \
intltool swig libmp3lame-dev libgavl-dev libsamplerate0-dev
libjack-dev libsoup2.4-dev \
python-dev libkf5crash-dev libkf5filemetadata-dev
After that, I also had to install
libqt5x11extras5-dev
However, something is still missing, because make build-nocheck now throws
the following error:
/home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:287:
error: undefined reference to
'configmgr::dconf::writeModifications(configmgr::Components&,
configmgr::Data&)'
/home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:531:
error: undefined reference to
'configmgr::dconf::readLayer(configmgr::Data&, int)'
/home/linux/libreoffice/libreoffice/configmgr/source/components.cxx:533:
error: undefined reference to
'configmgr::dconf::readLayer(configmgr::Data&, int)'
collect2: error: ld returned 1 exit status
/home/linux/libreoffice/libreoffice/Library_merged.mk:11: recipe for target
'/home/linux/libreoffice/libreoffice/instdir/program/libmergedlo.so' failed
make[1]: ***
[/home/linux/libreoffice/libreoffice/instdir/program/libmergedlo.so] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:282: recipe for target 'build' failed
make: *** [build] Error 2
Any idea what could be missing to successfully build the .deb files?
Thanks again for all your help.
El mié., 7 ago. 2019 a las 14:44, Michael Weghorn (<m.weghorn at posteo.de>)
escribió:
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20190808/4e673666/attachment.html>
More information about the LibreOffice
mailing list