Sunday, June 07, 2015

Building LibreOffice on Tribblix

Having decent tools is necessary for an operating system to be useful, and one of the basics for desktop use is an office suite - LibreOffice being the primary candidate.

Unfortunately, there aren't prebuilt binaries for any of the Solaris or illumos distros. So I've been trying to build LibreOffice from source for a while. Finally, I have a working build on Tribblix.

This is what I did. Hopefully it will be useful to other distros. This is just a straight dump of my notes.

First, you'll need java (the jdk), and the perl Archive::Zip module. You'll need boost, and harfbuzz with the icu extensions. Plus curl, hunspell, cairo, poppler, neon.

Then you'll need to build (look on this page for links to some of this stuff):

  • cppunit-1.13.2
  • librevenge-0.0.2
  • libwpd-0.10.0
  • libwpg-0.3.0
  • libmspub-0.1.2
  • libwps-0.3.1
  • mdds_0.11.2
  • libixion-0.7.0
  • liborcus-0.7.0
  • libvisio-0.1.1

If you don't tell it otherwise, LibreOffice will download these and try to build them itself. And generally these have problems building cleanly, which it's fairly easy to fix while building them in isolation, but would be well nigh impossible when they're buried deep inside the LibreOffice build system

For librevenge, pass --disable-werror to configure.

For libmspub, replace the call to pow() in src/lib/MSPUBMetaData.cpp with std::pow().

For libmspub, remove zlib from the installed pc file (Tribblix, and some of the other illumos other distros, don't supply a pkgconfig file for zlib).

For liborcus, run the following against all the Makefiles that the configure step generates:

gsed -i 's:-DMDDS_HASH_CONTAINER_BOOST:-pthreads -DMDDS_HASH_CONTAINER_BOOST:'

For mdds, make sure you have a PATH that has the gnu install ahead of the system install program when running make install.
For ixion, it's a bit more involved. You need some way of getting -pthreads past configure *and* make. For configure, I used:

env boost_cv_pthread_flag=-pthreads CFLAGS="-O -pthreads" CPPFLAGS="-pthreads" CXXFLAGS="-pthreads" configure ...

and for make:

gmake MDDS_CFLAGS=-pthreads

For orcus, it looks to pkgconfig to find zlib, so you'll need to prevent that:

 env ZLIB_CFLAGS="-I/usr/include" ZLIB_LIBS="-lz" configure ...

For libvisio, replace the call to pow() in src/lib/VSDMetaData.cpp with std::pow().

For libvisio, remove zlib and libxml-2.0 from the installed pc file.

If you want to run a parallel make, don't use gmake 3.81. Version 4.1 is fine.

With all those installed you can move on to LibreOffice.

Unpack the main tarball.

chmod a+x bin/unpack-sources
mkdir -p external/tarballs


and then symlink or copy the other tarballs (help, translations, dictionaries) into external/tarballs (otherwise, it'll try downloading them again).

Download and run this script to patch the builtin version of glew.

Edit the following files:

  • svx/Executable_gengal.mk
  • sw/Executable_tiledrendering.mk
  • vcl/Executable_ui-previewer.mk
  • desktop/Library_sofficeapp.mk
  • vcl/Library_vcl.mk

And replace "LINUX" with "SOLARIS". That part of the makefiles is needed on all unix-like systems, not just Linux.

In the file

sc/source/core/tool/interpr1.cxx

replace the call to pow() on line 3160 with std::pow()

In the file

sal/qa/inc/valueequal.hxx

replace the call to pow() on line 87 with std::pow()

In the file

include/vcl/window.hxx

You'll need to #undef TRANSPARENT before it's used (otherwise, it picks up a rogue definition from the system).

And you'll need to create a compilation symlink:

mkdir -p  instdir/program
ln -s libGLEW.so.1.10 instdir/program/libGLEW.so

This is the configure command I used:

env PATH=/usr/gnu/bin:$PATH \
./configure --prefix=/usr/versions/libreoffice-44 \
--with-system-hunspell \
--with-system-curl \
--with-system-libpng \
--with-system-clucene=no \
--with-system-libxml \
--with-system-jpeg=no \
--with-system-cairo \
--with-system-harfbuzz \
--with-gnu-cp=/usr/gnu/bin/cp \
--with-gnu-patch=/usr/gnu/bin/patch \
--disable-gconf \
--without-doxygen \
--with-system-openssl \
--with-system-nss \
--disable-python \
--with-system-expat \
--with-system-zlib \
--with-system-poppler \
--disable-postgresql-sdbc \
--with-system-icu \
--with-system-neon \
--disable-odk \
--disable-firebird-sdbc \
--without-junit \
--disable-gio \
--with-jdk-home=/usr/jdk/latest \
--disable-gltf \
--with-system-libwps \
--with-system-libwpg \
--with-system-libwpd \
--with-system-libmspub \
--with-system-librevenge \
--with-system-orcus \
--with-system-mdds \
--with-system-libvisio \
--with-help \
--with-vendor="Tribblix" \
--enable-release-build=yes \
--with-parallelism=8

and then to make:

env LD_LIBRARY_PATH=/usr/lib/mps:`pwd`/instdir/ure/lib:`pwd`/instdir/sdk/lib:`pwd`/instdir/program \
PATH=/usr/gnu/bin:$PATH \
/usr/gnu/bin/make -k build

(Using 'make build' is supposed to avoid the checks, many of which fail. You'll definitely need to run 'make -k' with a parallel build, because otherwise some of the test failures will stop the build before all the other parallel parts of the build have finished.)

Then create symlinks for all the .so files in /usr/lib/mps in instdir/program, and instdir/program/soffice should start.

7 comments:

Chris J said...

So with the LD_LIBRARY_PATH, you're overcoming a step that's breaking during the build phase, but you're not affecting the end locations of where LibreOffice will look for shared libraries?

Peter Tribble said...

Yes, the LD_LIBRARY_PATH is just for the build. I can fix some of the problems with symbolic links at install, and the soffice wrapper script sets LD_LIBRARY_PATH for runtime to catch the rest.

Anonymous said...

Forget the LD_LIBRARY_PATH.

If you set up the environment exactly as I tell you, you won't ever need to futz around with LD_LIBRARY_PATH, ever again:

setenv O '$$O'
setenv ORIGIN '$ORIGIN'
setenv LD_OPTIONS "-L/path/to/lib -R${ORIGIN}:${ORIGIN}/../../lib:${ORIGIN}/../lib:/path/to/lib"

LD_OPTIONS is the backdoor to the Solaris link editor, ld(1): what is in LD_OPTIONS gets appended to the final link stage.

I do this all the time, and it works like a charm. I have not set LD_LIBRARY_PATH in more than ten years, and I build tons and tons of software on Solaris almost every day.

Peter Tribble said...

Mucking with $ORIGIN won't help here. For one thing, various components are built in little sandboxes that could be anywhere, so relative paths won't work (and aren't adequately predictable or reproducible), and you absolutely don't want to pollute intermediate build artefacts with randomly incorrect RPATH settings. Fundamentally, there's no difference here between LD_OPTIONS and LD_LIBRARY_PATH - after all, what you're needing to do is fool the (overly complex and obfuscated) build process into working correctly.

Anonymous said...

There are no ill effects of having intermediate products with $ORIGIN - ten years and hundreds of complex build engines and packages later, I have yet to encounter such a case. (I used to do this for a living.)

LD_LIBRARY_PATH and LD_OPTIONS are two different animals. The former is intended for shared object library development, the latter for bypassing poorly written build engines. The former has transient, while the latter permanent effect.

Björn Michaelsen said...

Hi there,

great work!

A sidenote: If you really, really want to sidestep tests from the toplevel, there is the s3cr3t "make build.nocheck" target for that. This is really discouraged for average developers as one should always ensure not breaking these tests on the usual Windows/Linux/OSX platforms before submitting patches. The only valid scenario for "make build.nocheck" is if a package maintainer _knows_ his packaging to run the tests in a later phase ...

In a morbid way, I enjoy the fact that more trouble came from the external autotools-based projects than from LibreOffice/gbuild itself. ;) Please consider upstreaming as much as possible of these fixes[1] -- it will also make maintaining LibreOffice on Solaris easier in the end. And again: Kudos for this great work!

Best,

Bjoern

[1] https://gerrit.libreoffice.org/ -- and #libreoffice-dev IRC on freenode if you need help
(btw OpenID auth against Launchpad seems to be broken on blogger.com?)

Anonymous said...

Hi Peter,

why not setting up a tinderbox to get a notice / hint that new commits break your build? (see also https://wiki.documentfoundation.org/Development/Tinderbox)


Regards,

Dennis Roczek