1 Cross-compiling LibreOffice
2 ===========================
4 Notes on cross-compiling LibreOffice, originally written by Tor
5 Lillqvist <tlillqvist@novell.com> <tml@iki.fi> in May, 2011, for later
8 My cross-compilation experimentation is going on for four platforms:
9 Windows, iOS, Android and PowerPC Mac OS X. I work on the master
10 branch of LibreOffice. Some other people have talked about setting up
11 a separate branch for Android work, or even separate clones at
12 github. I am not interested in that.
14 Cross-compilation of LibreOffice completely is not possible yet. Much
15 work has been done, "baby steps" for some platforms, much more for
16 others, but a lot remains. For iOS and Android this work is highly
17 experimental and done mostly in my own spare time just for the hacking
18 pleasure. No promise, explicit or implied, is given that it will ever
21 Searching for information about cross-compilation of OpenOffice.org
22 (the predecessor of LibreOffice) you will find information about what
23 actually was not cross-compilation, but using QEMU.
29 In GNU Autoconf terminology, "build" is the platform on which you are
30 running a build on some software and "host" is the platform on which
31 the software you are building will run. Only in the specific case of
32 building compilers and other programming tools is the term "target"
33 used to indicate the platform for which the tools your are building
34 will produce code. As LibreOffice is not a compiler, the "target" term
35 should not be used in the context of cross-compilation.
37 (For a case where all three of "build", "host" and "target" are
38 different: consider a gcc cross-compiler running on Windows, producing
39 code for Android, where the cross-compiler itself was built on
40 Linux. (This is a real case.) An interesting tidbit is that such
41 configurations are called "Canadian Cross".)
43 Even though the LibreOffice build mechanism is highly unorthodox, the
44 configure script takes the normal --build and --host options like any
45 GNU Autoconf -based configure script. To cross-compile, you basically
46 need just to specify a suitable --host option and things should work
47 out nicely. In practise, some more details might be needed. See
51 What is so hard, then?
52 ----------------------
54 Despite the fact that the configure script takes normal --build and
55 --host options, that is just the beginning. In practise a lot of work
56 was necessary to separate tests for "host" and "build" platforms in
57 the configure script. See the git log for details. And the reasonably
58 "standard" configure.in is just the top level; when we get down to the
59 actual makefilery used to build the bits of LibreOffice, it gets much
66 There is some support in LibreOffice already (from OpenOffice.org) for
67 building it locally on Windows with the GNU tool-chain (MinGW). But as
68 far as I know, that work has never attempted cross-compilation.
70 This OOo-originated MinGW support attempts to support both running
71 Cygwin gcc in its -mno-cygwin mode, and a native MinGW compiler. The
72 -mno-cygwin mechanism in the Cygwin gcc is rapidly being obsoleted, if
73 it isn't already, and I have not attempted to try to keep it working;
74 in fact I have activly cleaned out mechanisms related to this. Ditto
75 for native MinGW. If one compiles natively on Windows, just use
76 Microsoft's compiler. OOo/LO has been built for Windows all the time
79 In my opinion, the only case where it makes sense to use MinGW is for
80 cross-compilation. There is just too much crack on Windows anyway, and
81 it is a semi-miracle (well, make that the result of years of work)
82 that the MSVC build under Cygwin works as nicely as it does.
84 MinGW is available as cross-build toolchains pre-packaged in more or
85 less official packages for many Linux distros including Debian, Fedora
86 and openSUSE. Personally I use the mingw32 packages in the openSUSE
87 Build Service, running on openSUSE:
89 http://download.opensuse.org/repositories/windows:/mingw:/win32/
91 You can install it on openSUSE like this:
93 zypper ar http://download.opensuse.org/repositories/windows:/mingw:/win32/SLE_11_SP1/windows:mingw:win32.repo
94 zypper in mingw32-cross-gcc mingw32-cross-gcc-c++ mingw32-python-devel \
95 mingw32-libexpat-devel mingw32-libexpat mingw32-boost-devel \
96 mingw32-libhyphen-devel mingw32-libhyphen mingw32-hyphen-en \
97 mingw32-liblpsolve mingw32-liblpsolve-devel \
98 mingw32-libxml2-devel mingw32-libxslt-devel mingw32-libicu \
99 mingw32-libicu-devel mingw32-libgraphite2 mingw32-libgraphite2-devel \
100 mingw32-cairo mingw32-cairo-devel mingw32-librsvg mingw32-librsvg-devel \
101 mingw32-hunspell mingw32-hunspell-devel mingw32-libcurl \
102 mingw32-libcurl-devel mingw32-libneon mingw32-libneon-devel \
103 mingw32-libopenssl mingw32-libopenssl-devel mingw32-libtextcat \
104 mingw32-libtextcat-devel mingw32-libdb mingw32-libdb-devel \
105 mingw32-cross-pkg-config mingw32-pkg-config mingw32-libcppunit \
106 mingw32-libcppunit-devel mingw32-libredland mingw32-libredland-devel \
107 mingw32-libmythes mingw32-libmythes-devel
109 There might be more that are missing, please read carefully what autogen.sh
110 tells you, and either remove one of the --with-system-*, or install the
113 It also looks like graphite2.pc needs tweaking in order to work right; but
114 that's likely to be fixed in the openSUSE project.
116 It is somewhat unclear how well thought-out the conditionals and code
117 for MinGW inside the OOo-originated code in LibreOffice actually
118 are. What I have noticed of it seems a bit randomish, with
119 copy-pasting having been preferred to factoring out differences.
121 The autogen.lastrun I use for my MinGW cross-compilation experimentation is:
123 CC=ccache i686-w64-mingw32-gcc
124 CXX=ccache i686-w64-mingw32-g++
125 CC_FOR_BUILD=ccache gcc
126 CXX_FOR_BUILD=ccache g++
127 --build=x86_64-unknown-linux-gnu
128 --host=i686-w64-mingw32
129 --with-distro=LibreOfficeWin32
132 --disable-build-mozilla
134 --disable-ext-nlpsolver
135 --disable-ext-pdfimport
136 --disable-ext-presenter-console
137 --disable-ext-presenter-minimizer
138 --disable-ext-report-builder
139 --disable-ext-scripting-beanshell
140 --disable-ext-scripting-javascript
141 --disable-ext-wiki-publisher
142 --disable-ext-wiki-publisher
145 --enable-python=system
146 --with-external-tar=/mnt/hemulen/ooo/git/master/src
149 --with-system-altlinuxhyph
152 --with-system-cppunit
156 --with-system-gettext
157 --with-system-hunspell
164 --with-system-libxslt
165 --with-system-lpsolve
168 --with-system-openssl
169 --with-system-redland
172 --without-helppack-integration
173 --without-myspell-dicts
178 - so far the make_installer.pl calls makecab.exe, uuidgen.exe, and
179 others; would be best to avoid that if at all possible (using a free
180 cab implementation, part of Wine or something)
182 - if at all possible, the make dev-install installation (with links
183 back to the build) should be done so that it would be directly
184 executable via wine after doing make dev-install :-)
187 - no idea if the entire thing works after the installation at all; I
188 suppose there will be runtime problems to look at too
191 - enable & fix pieces that are currently disabled
192 - --without-myspell-dicts
196 - much of the stuff currently relies on --with-system-*, and
197 consequently on the mingw32-* openSUSE packages; might be good to be
198 able to build with as few dependencies as possible - but that is low
202 - when all the above is sorted out, we should look at the speed of
203 this vs. the speed of the MSVC version
209 iOS is the operating system of Apple's mobile devices. Clearly for a
210 device like the iPad it would be totally unacceptable to run a normal
211 LibreOffice application with a overlapping windows and mouse-oriented
212 GUI widgets. No work has been done (at least publicly) to design a
213 touch GUI for LibreOffice, so the work on cross-compiling LibreOffice
214 for iOS is extremely experimental, and of course partly pointless;)
215 But it is interesting and fun nonetheless.
217 Obviously it will make sense to build only a part of LibreOffice's
218 code for iOS. Most likely all GUI-oriented code should be left out,
219 and some iOS app that eventually wants to use the remaining bits will
220 handle all its GUI in a platform-dependent manner. How well it will be
221 possible to do such a split remains to be seen. As I said, this is
222 highly experimental and just in its baby steps phase.
224 Technically, one important special aspect of iOS is that apps are not
225 allowed to load own dynamic libraries. (System libraries are used in
226 the form of dynamic libraries, just like on MacOSX, of which iOS is a
227 variant.) So all the libraries in LibreOffice that normally are shared
228 libraries (DLLs on Windows, shared objects (.so) on Linux, dynamic
229 libraries on MacOSX (.dylib)) need to be built as static archives
230 instead. Obviously this will have some interesting consequences for
231 how UNO is implemented and used. None of that has been spared much
234 The Apple tool-chain for iOS cross-building is available only for
235 MacOSX, so that is where I have been doing it.
237 Here is my autogen.lastrun for iOS (device):
238 CXX=ccache /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk
239 CC=ccache /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk
240 CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0
241 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0
242 --with-distro=LibreOfficeiOS
243 --with-external-tar=/Volumes/ooo/git/master/src
247 And here for the iOS simulator:
248 CXX=ccache /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/g++-4.2 -arch i386 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk
249 CC=ccache /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.2 -arch i386 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk
250 CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0
251 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0
252 --with-distro=LibreOfficeiOS
253 --with-external-tar=/Volumes/ooo/git/master/src
263 I don't know much about Android, but from a technical point of view it
264 is a kind of Linux, of course. As far as I know it is allowed for an
265 Android app to use shared objects, but if it isn't, then just the same
266 approach as used on iOS will need to be used.
268 As for the GUI, the same holds as said above for iOS.
270 I have done my Android cross-compilation work on Linux (openSUSE in
271 particular), but it could as well be done on MacOSX. The Android
272 cross-buld tool-chain (the "Native Development Kit", or NDK) is
273 available for Linux, MacOSX and Windows. (Trying to cross-compile from
274 Windows will probably drive you insane.)
276 Here is my autogen.lastrun for Android:
277 SYSBASE=/home/tml/android-ndk-r5c/platforms/android-9/arch-arm
278 CC=ccache /home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot /home/tml/android-ndk-r5c/platforms/android-9/arch-arm
279 CXX=ccache /home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-g++ --sysroot /home/tml/android-ndk-r5c/platforms/android-9/arch-arm -I /home/tml/android-ndk-r5c/sources/cxx-stl/gnu-libstdc++/include -I/home/tml/android-ndk-r5c/sources/cxx-stl/gnu-libstdc++/libs/armeabi-v7a/include -L/home/tml/android-ndk-r5c/sources/cxx-stl/gnu-libstdc++/libs/armeabi-v7a -fexceptions -frtti
280 AR=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ar
281 NM=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-nm
282 OBJDUMP=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-objdump
283 RANLIB=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ranlib
284 STRIP=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip
285 CC_FOR_BUILD=ccache gcc
286 CXX_FOR_BUILD=ccache g++
287 --build=x86_64-unknown-linux-gnu
289 --with-distro=LibreOfficeAndroid
290 --with-external-tar=/mnt/hemulen/ooo/git/master/src
299 Cross-compiling for PowerPC Mac OS X from Intel Mac OS X will probably
300 be easy. The APIs available should after all be closely identical to
301 those on Intel Mac OS X, and LibreOffice builds fine natively on
302 PowerPC Mac already. I have just started experimenting with it. My
303 autogen.lastrun looks like this:
305 CC=ccache /Xcode3/usr/bin/gcc-4.0 -arch ppc
306 CXX=ccache /Xcode3/usr/bin/g++-4.0 -arch ppc
307 CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0
308 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0
309 --build=i386-apple-darwin10.7.0
310 --host=powerpc-apple-darwin10
312 --disable-build-mozilla
313 --with-external-tar=/Volumes/ooo/git/master/src
317 That's all, thank you, and have a nice day. People with commit access,
318 feel free to edit this document, and add yourself below. Sorry for
319 writing now initially from such a personal point of view.
321 --Tor Lillqvist <tlillqvist@novell.com>, <tml@iki.fi>