Development/Building LibreOffice with Clang

From The Document Foundation Wiki
Jump to: navigation, search

Mac works with clang by default.

On Linux systems add the following to your autogen.input:


ccache users will need to set the following e.g. in ~/.bashrc (ccache is used automatically assuming it is installed and configured correctly) -- autogen will warn you if this isn't set.

export CCACHE_CPP2=1

You should also install the clang headers (clang-devel or your distro's equivalent) for the clang loplugin to build. Autogen will warn you if these are missing.

openSuse 12.3 is known to work without any further setup (assuming you have all official updates), read the rest of this page to ensure you have the correct dependencies when working with other linux systems.

Building LibreOffice with Clang

It is possible to build LibreOffice using the Clang compiler instead of the GCC compiler.

Bootstraping clang on Linux

See this article how to build clang on linux:

Using libc++/libc++abi with clang on Linux

Building LO against libc++ on an otherwise libstdc++ based system is known not to work. From private notes about a failed attempt to do that on Fedora 24 against trunk LLVM in 2016: "Doing build with Clang and against libc++/libc++abi, one unit test loads /lib64/ (linked against libstdc++), which throws a std::runtime_exception. Due to differences in mangled names of std::string in libstdc++ vs libc++, the std::runtime_exception ctor is picked from libstdc++, while the dtor (having the same mangled name in both) is picked from libc++abi, which unsurprisingly causes a SEGV in the non-matching dtor. Morale: building LO on Linux against libc++ doesn't actually work (although it often happens to), as system libs drag in dependencies on libstdc++ with clashing symbol names."

On Fedora 25 there is only libcxx and libcxx-devel package available, but no libcxxabi or libcxxabi-devel available. Is this intended? So the only way to use libc++/libc++abi on Linux x86_64 is to compile libc++/libc++abi from the source:


  • LibreOffice - Version 3.6 has been tested to build and work without problems on Linux. See below for Mac OS X details. Older LibreOffice versions may or may not build and work.
  • Clang - version 3.1+ works. Older versions may not work.
  • Some libraries may need to be upgraded, mostly because of Clang's stricter/earlier implementation of C++11.
    • Libstdc++ 4.6 is known to work. Other libstdc++ versions may need patching (see Clang C++11 status page for information and patches).
    • Boost 1.47 and older may need patching (see this page). Internal copy of Boost shipped with LibreOffice builds fine.
    • NSS may need a patch or upgrade. Internal copy of NSS shipped with LibreOffice builds fine.
    • Qt4 may need a patch or upgrade. See Qt bugreport for a patch.
  • Ccache [1] works. At least version 3.1.10 (not yet released as of January 8th 2013) is needed when using compiler plugins (--enable-dbgutil or --enable-compiler-plugins), 3.1.9 needs a patch, older versions need also another patch). Older versions (version 3.1.7, possibly older) work when not using plugins.


export CCACHE_CPP2=1

otherwise Clang will report preprocessed sources in error messages, print some warnings in header files it wouldn't print otherwise, and print warnings about unused options -D and -I.

  • Icecream [2] needs to be at least version 1.0 (not yet released as of January 8th 2013)
  • On recent Fedora 17, the included Clang (3.0) is unusable due to clang++ chokes on <complex>. However, a home-built Clang 3.1 works fine.


Configuring LibreOffice is done normally, except that Clang is used as the compiler:

$ ./ CC=clang CXX=clang++  ... plus the usual configure options, see Development/BuildingOnLinux

Otherwise the build should work just like when building with GCC.


Although Clang can be mostly used as a drop-in replacement for GCC, it is an entirely different compiler, so there may be Clang-specific problems. In general it is however normally usable.

  • Clang bug 12255 - -fvisibility-inlines-hidden is broken (LO configure check disables the usage of the flag), fixed for Clang 3.2
  • Clang bug 13303 - broken debugginfo (in some cases) for first function in .cxx, bugreport includes patch, fixed for Clang 3.2

There should be also a tinderbox using Clang as the compiler [3], so if there is a problem, it might be useful to check its status.


  • openSUSE : Users may install necessary packages from the home:llunak:clang repository. These packages also include some patches with fixes.


As Apple is working on phasing out GCC from their SDK and using Clang instead (although the "Apple GCC" is still available from MacPorts), it is important to get LibreOffice to build with Clang.

It is possible to build LibreOffice from master (end of July 2012) using Clang version 3.1+ and the resulting binaries appear to run correctly. Older versions of Clang will likely not work. Clang 3.1 was compiled from source to produce this build, so no attempts have been done with a recent Clang shipped by Apple with Xcode. (For example Clang version 2.1 tags/Apple/clang-163.7.1 is known to not work).


XCode 4 has been installed on the machine and using gcc-4.2 (non-LLVM) the configuration will do a successfull LibreOffice build, which will also launch correctly. Make sure any 64-bit binaries in the PATH (e.g. pkg-config) are hidden. If you happen to have the Mono Framework installed, hide /usr/bin/pkg-config.

For the clang build, the following worked:

 CC="clang -m32" CXX="clang++ -m32" ./ --with-num-cpus=8 --with-max-jobs=8 --prefix=/source/libo/prefix --with-macosx-sdk=10.6 --with-macosx-version-max-allowed=10.6 --with-macosx-version-min-required=10.5 --disable-mozilla --without-help --without-doxygen --without-myspell-dicts


  • Currently, the sw_filter_test unit test crashes. A patch to fix this issue has been posted to the libreoffice mailing list.
  • On subsequent builds, ld sometimes complains about "malformed archive TOC entry" when working on archive files. To fix this, simply remove the archive file from solver and the workdir. A proper fix should be investigated, perhaps this can simply be done by adding the right flag somewhere.

Future work

It would be very interesting to attempt a 64-bit build of LibreOffice on OS X (useful, because since Snow Leopard full 64-bit applications are a possibility).

Example setup

One scenario that at least works for me (Stephan Bergmann) is the below script, slightly updated from “Building on Mac OS X 10.7”:

set -ex -o pipefail

# On latest Mac OS X 10.7.4 with latest Xcode 4.3.2 (incl. Command Line Tools):

mkdir "${HOME?}"/Software/lo

svn checkout \
 # head revision 93808 as of 2012-05-31 19:00:20 +0000
 # "https" instead of "http" fails to work non-interactively due to:
 #   Error validating server certificate for '':
 #    - The certificate is not issued by a trusted authority. Use the
 #      fingerprint to validate the certificate manually!
 #   Certificate information:
 #    - Hostname: *
 #    - Valid: from Tue, 22 Feb 2011 17:29:43 GMT until Tue, 18 Mar 2014
 #      23:36:56 GMT
 #    - Issuer: 07969287,,
 #, Inc., Scottsdale, Arizona, US
 #    - Fingerprint:
 #      4d:ea:4a:77:55:ac:8e:2e:9e:11:8a:59:3d:ec:c7:45:7d:b0:72:19
 #   (R)eject, accept (t)emporarily or accept (p)ermanently?
(cd "${HOME?}"/Software/lo/mports-src/base && ./configure \
 --prefix="${HOME?}"/Software/lo/mports --with-no-root-privileges \
 --with-applications-dir="${HOME?}"/Software/lo/mports-apps \
 --with-tclpackage="${HOME?}"/Software/lo/mports-tcl && make && make install) \
 || exit 1
"${HOME?}"/Software/lo/mports/bin/port selfupdate
"${HOME?}"/Software/lo/mports/bin/port install libidl +universal
"${HOME?}"/Software/lo/mports/bin/port install automake doxygen grep pkgconfig

mkdir "${HOME?}"/Software/lo/bin
ln -s "${HOME?}"/Software/lo/mports/bin/aclocal "${HOME?}"/Software/lo/bin/
ln -s "${HOME?}"/Software/lo/mports/bin/autoconf "${HOME?}"/Software/lo/bin/
ln -s "${HOME?}"/Software/lo/mports/bin/autom4te "${HOME?}"/Software/lo/bin/
ln -s "${HOME?}"/Software/lo/mports/bin/doxygen "${HOME?}"/Software/lo/bin/

mkdir "${HOME?}"/Software/lo/pkgconfig
ln -s "${HOME?}"/Software/lo/mports/lib/pkgconfig/glib-2.0.pc \
ln -s "${HOME?}"/Software/lo/mports/lib/pkgconfig/libIDL-2.0.pc \

git clone ssh:// \

# moz/unxmacxi/misc/build/mozilla/configure:20225 fails with "egrep: Regular
# expression too big" with default /usr/bin/egrep ("egrep (GNU grep) 2.5.1"),
# and adding this replacement to "${HOME?}"/Software/lo/bin (which is added to
# PATH) does not help, as contains a rewritten PATH (where
# "${HOME?}"/Software/lo/bin would always go after /usr/bin):
ln -s "${HOME?}"/Software/lo/mports/bin/egrep \

# moz/unxmacxi/misc/build/mozilla/gfx/src/mac/nsRegionPool.cpp uses NewRgn,
# DisposeRgn, etc. that got removed in 10.7 SDK:
cat >"${HOME?}"/Software/lo/core/autogen.lastrun <<\EOF
--with-lang=de en-US
CC=clang -m32
CXX=clang++ -m32

ulimit -c unlimited

cd "${HOME?}"/Software/lo/core
printf '%s' "${HOME?}" | grep -Fqv : || exit 1
PATH=${PATH?}:${HOME?}/Software/lo/bin \
 PKG_CONFIG=${HOME?}/Software/lo/mports/bin/pkg-config \
 PKG_CONFIG_LIBDIR=${HOME?}/Software/lo/pkgconfig make check