Development/Building LibreOffice with Clang
From The Document Foundation Wiki
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:
- [[4]] (Match the correct function template specialization)
- [[5]] (Put neq-operator for awt::Size in correct namespace)
- [[6]] (Argument tot setTitle cannot be const)
- [[7]] (SystemFlavor NSStrings should not be const)
- [[8]] (Use NSString in template specification instead of objc_object)
- [[9]] (Also use .NET2003 build fix for Clang)
- [[10]] (Eliminate ambiguous conversion to cppu::OWeakObject)
- [[11]] (Eliminate ambiguous conversion to cppu::OWeakObject)
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).