The Document Foundation Wiki
 

Development/Building LibreOffice with Clang

From The Document Foundation Wiki

Jump to: navigation, search

Contents

Building LibreOffice with Clang

With some patching, it is possible to successfully complete a build of LibreOffice on Mac OS X using the Clang compiler [1]. This page describes the patches and modifications that were necessary to accomplish this.

(I managed to do this on Mac OS X Lion, with the Apple-provided Clang (version 2.1, tags/Apple/clang-163.7.1). Sadly, the produced app crashes when you try to launch it, for details see below. -KristianRietveld).

The problems faced during the build have been divided into three categories and are discussed below under Problems.

It would be interesting to attempt a build of LibreOffice using Clang on Linux as well.

Setup

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.

For the clang build, after hiding the 64-bit binaries in my PATH (e.g. pkg-config), the following worked:

 ./autogen.sh --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 CC="clang -arch i386" CXX="clang++ -arch i386"

However, note the visibility flag as detailed under "compiler issues". Usage of this should probably be disabled at autogen-time until Clang is fixed.

Problems

Compiler issues

Clang cannot compile the code in sal/osl/unx/interlck.c. The problematic line is:

    register oslInterlockedCount nCount asm("%eax");

which confuses Clang's register allocator. Removing the register specification at the end makes the build go through, but is of course not a correct fix. The best solution is likely to draft up a small test case to see if it happens in isolated test as well and submit this to the Clang bug tracker.


There are problems when building with -fvisibility=hidden. This first exposes itself when building the connectivity module (the modules before that build and link fine). It is possible that we are affected by this Clang bug: [[2]] (Bug 10113, Explicit template instantiation with default visibility fails to generate global symbols for certain types). The build finished fine after disabling this flag.


Clang is very slow on oox/source/drawingml/customshapepresets{1,2,3,4,5,6} and consumes a lot of memory. Building these files in parallel pushes a 8GB RAM machine out of memory.


LibreOffice C++ issues

You need LibreOffice from master, at least including commit [[3]] from Stephan Bergmann.

For the remaining issues, patches have been submitted to the mailing list. As of October 24, these have all been pushed to the master branch:

Misc. issues

The following flags passed to Clang are not used: "-malign-natural" and "-fno-enforce-eh-specs".

Crash on start up

When trying to launch the resulting LibreOffice app on Mac, a crash occurs in ConfigManager::AcquireTree. This happens when trying to assign a value to a Sequence of Any (pArgs), somewhere in the UNO code a NULL/bogus pointer is read.

(Before continuing to debug this, I would first want to do another clean rebuild of LibreOffice to see if that possibly solves the problem -KristianRietveld).

Personal tools
Namespaces
Variants
Actions
Wiki
Navigation
Toolbox
donate