README.cross

   1 Cross-compiling LibreOffice
   2 ===========================
   3
   4 Notes on cross-compiling LibreOffice, originally written by Tor
   5 Lillqvist <tlillqvist@novell.com> <tml@iki.fi> in May, 2011, for later
   6 history see git log.
   7
   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.
  13
  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
  19 be finished.
  20
  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.
  24
  25
  26 General
  27 -------
  28
  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.
  36
  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".)
  42
  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
  48 examples below.
  49
  50
  51 What is so hard, then?
  52 ----------------------
  53
  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
  60 worse.
  61
  62
  63 Windows
  64 -------
  65
  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.
  69
  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
  77 using that.
  78
  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.
  83
  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 openSUSE and SLE. Personally I use the mingw32 packages in the Open
  87 Build Service, running on openSUSE:
  88
  89 http://download.opensuse.org/repositories/windows:/mingw:/win32/
  90
  91 For example, you can install it like this:
  92
  93 zypper ar http://download.opensuse.org/repositories/windows:/mingw:/win32/<your_os>/windows:mingw:win32.repo
  94
  95 where <your_os> is one of SLE_11, SLE_11_SP1, openSUSE_11.3, openSUSE_11.4 or
  96 openSUSE_Factory.
  97
  98 zypper in mingw32-cross-gcc mingw32-cross-gcc-c++ mingw32-python-devel \
  99     mingw32-libexpat-devel mingw32-libexpat mingw32-boost-devel \
 100     mingw32-libhyphen-devel mingw32-libhyphen mingw32-hyphen-en \
 101     mingw32-liblpsolve mingw32-liblpsolve-devel \
 102     mingw32-libxml2-devel mingw32-libxslt-devel mingw32-libicu \
 103     mingw32-libicu-devel mingw32-libgraphite2 mingw32-libgraphite2-devel \
 104     mingw32-libcairo2 mingw32-cairo-devel mingw32-librsvg mingw32-librsvg-devel \
 105     mingw32-hunspell mingw32-hunspell-devel mingw32-libcurl \
 106     mingw32-libcurl-devel mingw32-libneon mingw32-libneon-devel \
 107     mingw32-libopenssl mingw32-libopenssl-devel mingw32-libexttextcat \
 108     mingw32-libexttextcat-devel mingw32-libdb mingw32-libdb-devel \
 109     mingw32-cross-pkg-config mingw32-pkg-config mingw32-libcppunit \
 110     mingw32-libcppunit-devel mingw32-libredland mingw32-libredland-devel \
 111     mingw32-libmythes mingw32-libmythes-devel
 112
 113 There might be more that are missing, please read carefully what autogen.sh
 114 tells you, and either remove one of the --with-system-*, or install the
 115 missing dependency.
 116
 117 It also looks like graphite2.pc needs tweaking in order to work right; but
 118 that's likely to be fixed in the openSUSE project.
 119
 120 It is somewhat unclear how well thought-out the conditionals and code
 121 for MinGW inside the OOo-originated code in LibreOffice actually
 122 are. What I have noticed of it seems a bit randomish, with
 123 copy-pasting having been preferred to factoring out differences.
 124
 125 The autogen.lastrun I use for my MinGW cross-compilation experimentation is:
 126
 127 CC=ccache i686-w64-mingw32-gcc
 128 CXX=ccache i686-w64-mingw32-g++
 129 CC_FOR_BUILD=ccache gcc
 130 CXX_FOR_BUILD=ccache g++
 131 --build=x86_64-unknown-linux-gnu
 132 --host=i686-w64-mingw32
 133 --with-distro=LibreOfficeWin32
 134 --disable-activex
 135 --disable-binfilter
 136 --disable-build-mozilla
 137 --disable-directx
 138 --disable-ext-nlpsolver
 139 --disable-ext-pdfimport
 140 --disable-ext-presenter-console
 141 --disable-ext-presenter-minimizer
 142 --disable-ext-report-builder
 143 --disable-ext-scripting-beanshell
 144 --disable-ext-scripting-javascript
 145 --disable-ext-wiki-publisher
 146 --disable-ext-wiki-publisher
 147 --disable-mozilla
 148 --disable-nss-module
 149 --disable-zenity
 150 --enable-python=system
 151 --with-external-tar=/mnt/hemulen/ooo/git/master/src
 152 --with-num-cpus=1
 153 --with-max-jobs=1
 154 --with-system-altlinuxhyph
 155 --with-system-boost
 156 --with-system-cairo
 157 --with-system-cppunit
 158 --with-system-curl
 159 --with-system-db
 160 --with-system-expat
 161 --with-system-gettext
 162 --with-system-hunspell
 163 --with-system-icu
 164 --with-system-libpng
 165 --with-system-libwpd
 166 --with-system-libwpg
 167 --with-system-libwps
 168 --with-system-libxml
 169 --with-system-libxslt
 170 --with-system-lpsolve
 171 --with-system-mythes
 172 --with-system-neon
 173 --with-system-openssl
 174 --with-system-redland
 175 --with-vendor=no
 176 --without-help
 177 --without-helppack-integration
 178 --without-myspell-dicts
 179
 180 For reference, Kendy's autogen.lastrun is:
 181
 182 CC=ccache i686-w64-mingw32-gcc
 183 CXX=ccache i686-w64-mingw32-g++
 184 CC_FOR_BUILD=ccache gcc
 185 CXX_FOR_BUILD=ccache g++
 186 --build=x86_64-unknown-linux-gnu
 187 --host=i686-w64-mingw32
 188 --with-num-cpus=4
 189 --with-max-jobs=8
 190 --without-junit
 191 --disable-binfilter
 192 --disable-build-mozilla
 193 --disable-mozilla
 194 --disable-nss-module
 195 --with-system-altlinuxhyph
 196 --with-system-boost
 197 --with-system-cairo
 198 --with-system-cppunit
 199 --with-system-curl
 200 --with-system-db
 201 --with-system-expat
 202 --with-system-gettext
 203 --with-system-graphite
 204 --with-system-hunspell
 205 --with-system-icu
 206 --with-system-libpng
 207 --with-system-libxml
 208 --with-system-libxslt
 209 --with-system-lpsolve
 210 --with-system-mythes
 211 --with-system-neon
 212 --with-system-openssl
 213 --with-system-redland
 214 --without-myspell-dicts
 215 --disable-directx
 216 --disable-activex
 217 --disable-extension-integration
 218
 219 Once you have compiled it, you may want to try to run it:
 220
 221 $ cd /tmp
 222 $ tar xf <your-build-dir>/instsetoo_native/wntgcci.pro/LibreOffice_Dev/archive/install/en-US/LibO-Dev_OOO350m1_Win_x86_install-arc_en-US.tar.gz
 223 $ cd LibO-Dev_OOO350m1_Win_x86_install-arc_en-US/LibO-dev\ 3.5/program
 224 $ wine soffice.exe
 225
 226 NB. it is important to unpack somewhere low in the hierarchy structure (like
 227 in /tmp as advised above), otherwise you'll get BerkeleyDB errors on startup.
 228
 229 And if you are brave enough, you can even debug it.  First you have to add the
 230 URE dll's to the wine's PATH using 'wine regedit' - see
 231 http://www.winehq.org/docs/wineusr-guide/environment-variables, and add
 232 Z:\tmp\LibO-Dev_OOO350m1_Win_x86_install-arc_en-US\LibO-dev 3.5\URE\bin
 233 to "Path" in My Computer->HKEY_CURRENT_USER->Environment.
 234
 235 Then run linkoo, so that when you rebuild something, you can directly see the
 236 changes the next time you run it:
 237
 238 solenv/bin/linkoo '/tmp/LibO-Dev_OOO350m1_Win_x86_install-arc_en-US/LibO-dev 3.5' <your_clone_dir>
 239
 240 And start debugging:
 241
 242 $ winedbg soffice.bin
 243
 244 Would be great to be able to use winedbg --gdb, but it was crashing here :-( -
 245 but maybe you'll be more lucky.
 246
 247 TODO:
 248
 249 - installation
 250   - so far the make_installer.pl calls makecab.exe, uuidgen.exe, and
 251     others; would be best to avoid that if at all possible (using a free
 252     cab implementation, part of Wine or something)
 253   - MSI generation
 254   - if at all possible, the make dev-install installation (with links
 255     back to the build) should be done so that it would be directly
 256     executable via wine after doing make dev-install :-)
 257
 258 - runtime
 259   - no idea if the entire thing works after the installation at all; I
 260     suppose there will be runtime problems to look at too
 261
 262 - cleanup
 263   - enable & fix pieces that are currently disabled
 264     - --without-myspell-dicts
 265     - --disable-directx
 266     - --disable-activex
 267     - --disable-mozilla
 268   - much of the stuff currently relies on --with-system-*, and
 269     consequently on the mingw32-* openSUSE packages; might be good to be
 270     able to build with as few dependencies as possible - but that is low
 271     prio I think
 272
 273 - profiling
 274   - when all the above is sorted out, we should look at the speed of
 275     this vs. the speed of the MSVC version
 276
 277
 278 iOS
 279 ---
 280
 281 iOS is the operating system of Apple's mobile devices. Clearly for a
 282 device like the iPad it would be totally unacceptable to run a normal
 283 LibreOffice application with a overlapping windows and mouse-oriented
 284 GUI widgets. No work has been done (at least publicly) to design a
 285 touch GUI for LibreOffice, so the work on cross-compiling LibreOffice
 286 for iOS is extremely experimental, and of course partly pointless;)
 287 But it is interesting and fun nonetheless.
 288
 289 Obviously it will make sense to build only a part of LibreOffice's
 290 code for iOS. Most likely all GUI-oriented code should be left out,
 291 and some iOS app that eventually wants to use the remaining bits will
 292 handle all its GUI in a platform-dependent manner. How well it will be
 293 possible to do such a split remains to be seen. As I said, this is
 294 highly experimental and just in its baby steps phase.
 295
 296 Technically, one important special aspect of iOS is that apps are not
 297 allowed to load own dynamic libraries. (System libraries are used in
 298 the form of dynamic libraries, just like on MacOSX, of which iOS is a
 299 variant.) So all the libraries in LibreOffice that normally are shared
 300 libraries (DLLs on Windows, shared objects (.so) on Linux, dynamic
 301 libraries on MacOSX (.dylib)) need to be built as static archives
 302 instead. Obviously this will have some interesting consequences for
 303 how UNO is implemented and used. None of that has been spared much
 304 thought yet.
 305
 306 The Apple tool-chain for iOS cross-building is available only for
 307 MacOSX, so that is where I have been doing it.
 308
 309 Here is my autogen.lastrun for iOS (device):
 310 CXX=ccache /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk
 311 CC=ccache /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk
 312 CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0
 313 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0
 314 --with-distro=LibreOfficeiOS
 315 --with-external-tar=/Volumes/ooo/git/master/src
 316 --with-num-cpus=1
 317 --with-max-jobs=1
 318
 319 And here for the iOS simulator:
 320 CXX=ccache /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/g++-4.2 -arch i386 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk
 321 CC=ccache /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.2 -arch i386 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk
 322 CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0
 323 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0
 324 --with-distro=LibreOfficeiOS
 325 --with-external-tar=/Volumes/ooo/git/master/src
 326 --with-num-cpus=1
 327 --with-max-jobs=1
 328 --disable-librsvg
 329 --enable-debug
 330
 331
 332 Android
 333 -------
 334
 335 I don't know much about Android, but from a technical point of view it
 336 is a kind of Linux, of course. As far as I know it is allowed for an
 337 Android app to use shared objects, but if it isn't, then just the same
 338 approach as used on iOS will need to be used.
 339
 340 As for the GUI, the same holds as said above for iOS.
 341
 342 I have done my Android cross-compilation work on Linux (openSUSE in
 343 particular), but it could as well be done on MacOSX. The Android
 344 cross-buld tool-chain (the "Native Development Kit", or NDK) is
 345 available for Linux, MacOSX and Windows. (Trying to cross-compile from
 346 Windows will probably drive you insane.)
 347
 348 Here is my autogen.lastrun for Android:
 349 SYSBASE=/home/tml/android-ndk-r6/platforms/android-9/arch-arm
 350 CC=ccache /home/tml/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot /home/tml/android-ndk-r6/platforms/android-9/arch-arm
 351 CXX=ccache /home/tml/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-g++ --sysroot /home/tml/android-ndk-r6/platforms/android-9/arch-arm -I /home/tml/android-ndk-r6/sources/cxx-stl/gnu-libstdc++/include -I/home/tml/android-ndk-r6/sources/cxx-stl/gnu-libstdc++/libs/armeabi-v7a/include -L/home/tml/android-ndk-r6/sources/cxx-stl/gnu-libstdc++/libs/armeabi-v7a -fexceptions -frtti
 352 AR=/home/tml/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ar
 353 NM=/home/tml/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-nm
 354 OBJDUMP=/home/tml/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-objdump
 355 RANLIB=/home/tml/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ranlib
 356 STRIP=/home/tml/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip
 357 CC_FOR_BUILD=ccache gcc
 358 CXX_FOR_BUILD=ccache g++
 359 --build=x86_64-unknown-linux-gnu
 360 --disable-zenity
 361 --with-distro=LibreOfficeAndroid
 362 --with-external-tar=/mnt/hemulen/ooo/git/master/src
 363 --disable-python
 364 --with-num-cpus=1
 365 --with-max-jobs=1
 366 --without-helppack-integration
 367 --without-myspell-dicts
 368
 369
 370 PowerPC Mac OS X
 371 ----------------
 372
 373 Cross-compiling for PowerPC Mac OS X from Intel Mac OS X will probably
 374 be easy. The APIs available should after all be closely identical to
 375 those on Intel Mac OS X, and LibreOffice builds fine natively on
 376 PowerPC Mac already. I have just started experimenting with it. My
 377 autogen.lastrun looks like this:
 378
 379 CC=ccache /Xcode3/usr/bin/gcc-4.0 -arch ppc
 380 CXX=ccache /Xcode3/usr/bin/g++-4.0 -arch ppc
 381 CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0
 382 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0
 383 --build=i386-apple-darwin10.7.0
 384 --host=powerpc-apple-darwin10
 385 --disable-mozilla
 386 --disable-build-mozilla
 387 --with-external-tar=/Volumes/ooo/git/master/src
 388
 389
 390
 391 That's all, thank you, and have a nice day. People with commit access,
 392 feel free to edit this document, and add yourself below. Sorry for
 393 writing now initially from such a personal point of view.
 394
 395 --Tor Lillqvist <tlillqvist@novell.com>, <tml@iki.fi>