430 lines
18 KiB
Text
430 lines
18 KiB
Text
Cross-compiling LibreOffice
|
|
===========================
|
|
|
|
The cross-compilation experimentation is going on for four platforms:
|
|
Windows, iOS, Android and PowerPC Mac OS X. It happens in the master
|
|
branch of LibreOffice. Some people have talked about setting up a
|
|
separate branch for Android work, or even separate clones at github,
|
|
but that is not necessary.
|
|
|
|
Cross-compilation of LibreOffice completely is not possible yet. Much
|
|
work has been done, "baby steps" for some platforms, much more for
|
|
others, but a lot remains. For iOS and Android this work is highly
|
|
experimental, originally done in spare time just for the hacking
|
|
pleasure. No promise, explicit or implied, is given that it will ever
|
|
be finished.
|
|
|
|
Searching for information about cross-compilation of OpenOffice.org
|
|
(the predecessor of LibreOffice) you will find information about what
|
|
actually was not cross-compilation, but using QEMU.
|
|
|
|
|
|
General
|
|
-------
|
|
|
|
In GNU Autoconf terminology, "build" is the platform on which you are
|
|
running a build on some software and "host" is the platform on which
|
|
the software you are building will run. Only in the specific case of
|
|
building compilers and other programming tools is the term "target"
|
|
used to indicate the platform for which the tools your are building
|
|
will produce code. As LibreOffice is not a compiler, the "target" term
|
|
should not be used in the context of cross-compilation.
|
|
|
|
(For a case where all three of "build", "host" and "target" are
|
|
different: consider a gcc cross-compiler running on Windows, producing
|
|
code for Android, where the cross-compiler itself was built on
|
|
Linux. (This is a real case.) An interesting tidbit is that such
|
|
configurations are called "Canadian Cross".)
|
|
|
|
Even though the LibreOffice build mechanism is highly unorthodox, the
|
|
configure script takes the normal --build and --host options like any
|
|
GNU Autoconf -based configure script. To cross-compile, you basically
|
|
need just to specify a suitable --host option and things should work
|
|
out nicely. In practise, many details needed to be handled. See
|
|
examples below.
|
|
|
|
|
|
What is so hard, then?
|
|
----------------------
|
|
|
|
Despite the fact that the configure script takes normal --build and
|
|
--host options, that is just the beginning. In practise a lot of work
|
|
was necessary to separate tests for "host" and "build" platforms in
|
|
the configure script. See the git log for details. And the reasonably
|
|
"standard" configure.in is just the top level; when we get down to the
|
|
actual makefilery used to build the bits of LibreOffice, it gets much
|
|
worse.
|
|
|
|
|
|
Windows
|
|
-------
|
|
|
|
There is some support in LibreOffice already (from OpenOffice.org) for
|
|
building it locally on Windows with the GNU tool-chain
|
|
(MinGW). Apparently, that work has never attempted cross-compilation.
|
|
|
|
This OOo-originated MinGW support attempts to support both running
|
|
Cygwin gcc in its -mno-cygwin mode, and a native MinGW compiler. The
|
|
-mno-cygwin mechanism in the Cygwin gcc is rapidly being obsoleted, if
|
|
it isn't already, and we have not attempted to try to keep it working;
|
|
in fact we have activly cleaned out mechanisms related to this. Ditto
|
|
for native MinGW. If one compiles natively on Windows, just use
|
|
Microsoft's compiler. OOo/LO has been built for Windows all the time
|
|
using that.
|
|
|
|
The only case where it makes sense to use MinGW is for
|
|
cross-compilation. There is just too much crack on Windows anyway, and
|
|
it is a semi-miracle (well, make that the result of years of work)
|
|
that the MSVC build under Cygwin works as nicely as it does.
|
|
|
|
MinGW is available as cross-build toolchains pre-packaged in more or
|
|
less official packages for many Linux distros including Debian,
|
|
Fedora, openSUSE and SLE. For instance the mingw32 packages in the
|
|
Open Build Service, running on openSUSE:
|
|
|
|
http://download.opensuse.org/repositories/windows:/mingw:/win32/
|
|
|
|
For example, you can install it like this:
|
|
|
|
zypper ar http://download.opensuse.org/repositories/windows:/mingw:/win32/<your_os>/windows:mingw:win32.repo
|
|
|
|
where <your_os> is one of SLE_11, SLE_11_SP1, openSUSE_11.3, openSUSE_11.4 or
|
|
openSUSE_Factory.
|
|
|
|
zypper in mingw32-cross-gcc mingw32-cross-gcc-c++ mingw32-python-devel \
|
|
mingw32-libexpat-devel mingw32-libexpat mingw32-boost-devel \
|
|
mingw32-libhyphen-devel mingw32-libhyphen mingw32-hyphen-en \
|
|
mingw32-liblpsolve mingw32-liblpsolve-devel \
|
|
mingw32-libxml2-devel mingw32-libxslt-devel mingw32-libicu \
|
|
mingw32-libicu-devel mingw32-libgraphite2 mingw32-libgraphite2-devel \
|
|
mingw32-libcairo2 mingw32-cairo-devel mingw32-librsvg mingw32-librsvg-devel \
|
|
mingw32-hunspell mingw32-hunspell-devel mingw32-libcurl \
|
|
mingw32-libcurl-devel mingw32-libneon mingw32-libneon-devel \
|
|
mingw32-libopenssl mingw32-libopenssl-devel mingw32-libexttextcat \
|
|
mingw32-libexttextcat-devel mingw32-libdb mingw32-libdb-devel \
|
|
mingw32-cross-pkg-config mingw32-pkg-config mingw32-libcppunit \
|
|
mingw32-libcppunit-devel mingw32-libredland mingw32-libredland-devel \
|
|
mingw32-libmythes mingw32-libmythes-devel
|
|
|
|
There might be more that are missing, please read carefully what autogen.sh
|
|
tells you, and either remove one of the --with-system-*, or install the
|
|
missing dependency.
|
|
|
|
It also looks like graphite2.pc needs tweaking in order to work right; but
|
|
that's likely to be fixed in the openSUSE project.
|
|
|
|
It is somewhat unclear how well thought-out the conditionals and code
|
|
for MinGW inside the OOo-originated code in LibreOffice actually
|
|
are. It often seems a bit randomish, with copy-pasting having been
|
|
preferred to factoring out differences.
|
|
|
|
Most of the configuration settings are maintained in the
|
|
distro-configs/LibreOfficeMinGW.conf file, so in your autogen.lastrun,
|
|
you can use:
|
|
|
|
CC=ccache i686-w64-mingw32-gcc
|
|
CXX=ccache i686-w64-mingw32-g++
|
|
CC_FOR_BUILD=ccache gcc
|
|
CXX_FOR_BUILD=ccache g++
|
|
--with-distro=LibreOfficeMinGW
|
|
|
|
Alternatively, you can use something like the following; but the
|
|
preferred way is to keep the LibreOfficeMinGW.conf file up-to-date.
|
|
|
|
CC=ccache i686-w64-mingw32-gcc
|
|
CXX=ccache i686-w64-mingw32-g++
|
|
CC_FOR_BUILD=ccache gcc
|
|
CXX_FOR_BUILD=ccache g++
|
|
--build=x86_64-unknown-linux-gnu
|
|
--host=i686-w64-mingw32
|
|
--with-distro=LibreOfficeWin32
|
|
--disable-activex
|
|
--disable-binfilter
|
|
--disable-build-mozilla
|
|
--disable-directx
|
|
--disable-ext-nlpsolver
|
|
--disable-ext-pdfimport
|
|
--disable-ext-presenter-console
|
|
--disable-ext-presenter-minimizer
|
|
--disable-ext-report-builder
|
|
--disable-ext-scripting-beanshell
|
|
--disable-ext-scripting-javascript
|
|
--disable-ext-wiki-publisher
|
|
--disable-ext-wiki-publisher
|
|
--disable-mozilla
|
|
--disable-nss-module
|
|
--disable-zenity
|
|
--enable-python=system
|
|
--with-system-altlinuxhyph
|
|
--with-system-boost
|
|
--with-system-cairo
|
|
--with-system-cppunit
|
|
--with-system-curl
|
|
--with-system-db
|
|
--with-system-expat
|
|
--with-system-gettext
|
|
--with-system-hunspell
|
|
--with-system-icu
|
|
--with-system-libpng
|
|
--with-system-libwpd
|
|
--with-system-libwpg
|
|
--with-system-libwps
|
|
--with-system-libxml
|
|
--with-system-lpsolve
|
|
--with-system-mythes
|
|
--with-system-neon
|
|
--with-system-openssl
|
|
--with-system-redland
|
|
--with-vendor=no
|
|
--without-help
|
|
--without-helppack-integration
|
|
--without-myspell-dicts
|
|
|
|
Once you have compiled it, you may want to try to run it:
|
|
|
|
$ cd /tmp
|
|
$ tar xf <your-build-dir>/instsetoo_native/wntgcci.pro/LibreOffice_Dev/archive/install/en-US/LibO-Dev_3.6.0alpha0_Win_x86_install-arc_en-US.tar.gz
|
|
$ cd LibO-Dev_3.6.0alpha0_Win_x86_install-arc_en-US/LOdev\ 3.6/program
|
|
$ wine soffice.exe
|
|
|
|
NB. it is important to unpack somewhere low in the hierarchy structure (like
|
|
in /tmp as advised above), otherwise you'll get BerkeleyDB errors on startup.
|
|
|
|
And if you are brave enough, you can even debug it. First you have to add the
|
|
URE dll's to the wine's PATH using 'wine regedit' - see
|
|
http://www.winehq.org/docs/wineusr-guide/environment-variables, and add
|
|
Z:\tmp\LibO-Dev_3.6.0alpha0_Win_x86_install-arc_en-US\LOdev 3.6\URE\bin
|
|
to "Path" in My Computer->HKEY_CURRENT_USER->Environment.
|
|
|
|
Then run linkoo, so that when you rebuild something, you can directly see the
|
|
changes the next time you run it:
|
|
|
|
solenv/bin/linkoo '/tmp/LibO-Dev_3.6.0alpha0_Win_x86_install-arc_en-US/LOdev 3.6' <your_clone_dir>
|
|
|
|
And start debugging:
|
|
|
|
$ winedbg soffice.bin
|
|
|
|
Would be great to be able to use winedbg --gdb, but it was crashing here :-( -
|
|
but maybe you'll be more lucky.
|
|
|
|
Tricks of some use with winedbg:
|
|
--------------------------------
|
|
|
|
To examine OUStrings, you might want to use the following trick (prints 50
|
|
unicode characters of rLibName OUString - the +10 is where the buffer starts):
|
|
|
|
Wine-dbg>x /50u rLibName->pData+10
|
|
0x0909b6c8: vnd.sun.star.expand:$LO_LIB_DIR/abplo.dll
|
|
|
|
TODO:
|
|
|
|
- installation
|
|
- so far the make_installer.pl calls makecab.exe, uuidgen.exe, and
|
|
others; would be best to avoid that if at all possible (using a free
|
|
cab implementation, part of Wine or something)
|
|
- MSI generation
|
|
- if at all possible, the make dev-install installation (with links
|
|
back to the build) should be done so that it would be directly
|
|
executable via wine after doing make dev-install :-)
|
|
|
|
- runtime
|
|
- no idea if the entire thing works after the installation at all; I
|
|
suppose there will be runtime problems to look at too
|
|
|
|
- cleanup
|
|
- enable & fix pieces that are currently disabled
|
|
- --without-myspell-dicts
|
|
- --disable-directx
|
|
- --disable-activex
|
|
- --disable-mozilla
|
|
- much of the stuff currently relies on --with-system-*, and
|
|
consequently on the mingw32-* openSUSE packages; might be good to be
|
|
able to build with as few dependencies as possible - but that is low
|
|
prio
|
|
|
|
- profiling
|
|
- when all the above is sorted out, we should look at the speed of
|
|
this vs. the speed of the MSVC version
|
|
|
|
|
|
iOS
|
|
---
|
|
|
|
iOS is the operating system of Apple's mobile devices. Clearly for a
|
|
device like the iPad it would be totally unacceptable to run a normal
|
|
LibreOffice application with a overlapping windows and mouse-oriented
|
|
GUI widgets. No work has been done (at least publicly) by others to
|
|
design a touch GUI for LibreOffice, so that is something that needs to
|
|
be done.
|
|
|
|
Obviously it will make sense to use only a part of LibreOffice's code
|
|
for iOS. Most likely lots of the GUI-oriented code should be left out,
|
|
and some iOS app(s) that eventually wants to use the remaining bits
|
|
will handle all its GUI in a platform-dependent manner. How well it
|
|
will be possible to do such a split remains to be seen.
|
|
|
|
Technically, one important special aspect of iOS is that apps are not
|
|
allowed to load own dynamic libraries. (System libraries are used in
|
|
the form of dynamic libraries, just like on Mac OS X, of which iOS is a
|
|
variant.) So all the libraries in LibreOffice that normally are shared
|
|
libraries (DLLs on Windows, shared objects (.so) on Linux, dynamic
|
|
libraries on Mac OS X (.dylib)) need to be built as static archives
|
|
instead. Obviously this will have some interesting consequences for
|
|
how UNO is implemented and used. None of that has been spared much
|
|
thought yet.
|
|
|
|
The Apple tool-chain for iOS cross-building is available only for
|
|
Mac OS X.
|
|
|
|
Here is an autogen.lastrun for iOS (device) using Xcode 4.3 and clang:
|
|
CXX=ccache /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk
|
|
CC=ccache /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk
|
|
CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 -mmacosx-version-min=10.4
|
|
CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 -mmacosx-version-min=10.4
|
|
--with-distro=LibreOfficeiOS
|
|
--with-system-nss
|
|
--without-help
|
|
--without-helppack-integration
|
|
--without-myspell-dicts
|
|
|
|
And here for the iOS simulator, using Xcode 4.2 and gcc:
|
|
CXX=ccache /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/g++ -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk
|
|
CC=ccache /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk
|
|
CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 -mmacosx-version-min=10.4
|
|
CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 -mmacosx-version-min=10.4
|
|
--with-distro=LibreOfficeiOS
|
|
--with-system-nss
|
|
--enable-debug
|
|
--without-help
|
|
--without-helppack-integration
|
|
--without-myspell-dicts
|
|
|
|
It seems that with the latest iOS SDK one has to do:
|
|
sudo ln -s i686-apple-darwin10 /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk/usr/include/c++/4.2.1/i686-apple-darwin11
|
|
or g++ won't find its headers like <bits/c++config.h>
|
|
|
|
The --with-system-nss doesn't mean that any Mozilla NSS would be used,
|
|
it's just a trick to bypass some tests in the configure script.
|
|
|
|
For the iOS simulator, using Xcode 4.3 and gcc (should switch to clang here, too):
|
|
CXX=ccache /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/g++ -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk
|
|
CC=ccache /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk
|
|
CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 -mmacosx-version-min=10.4
|
|
CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 -mmacosx-version-min=10.4
|
|
--enable-werror
|
|
--with-distro=LibreOfficeiOS
|
|
--with-system-nss
|
|
--without-help
|
|
--without-helppack-integration
|
|
--without-myspell-dicts
|
|
|
|
Note that you will have to install autoconf and automake yourself
|
|
before running autogen.sh. They are no longer included in Xcode 4.3
|
|
(not even in the add-on "command line tools").
|
|
|
|
|
|
Android
|
|
-------
|
|
|
|
From a technical point of view the core Android OS is Linux, but
|
|
everything else is different. Unlike iOS, an Android app can use
|
|
shared objects just fine, so that aspect of UNO doesn't need special
|
|
handling.
|
|
|
|
As for the GUI, the same holds as said above for iOS.
|
|
|
|
Android cross-compilation work has been done on Linux (openSUSE in
|
|
particular) and Mac OS X. The Android cross-buld tool-chain (the
|
|
"Native Development Kit", or NDK) is available for Linux, Mac OS X and
|
|
Windows. (Trying to cross-compile from Windows will probably drive you
|
|
insane.)
|
|
|
|
Here is an autogen.lastrun for Android, when cross-compiling from Mac OS X:
|
|
|
|
CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 -mmacosx-version-min=10.4
|
|
CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 -mmacosx-version-min=10.4
|
|
--with-android-ndk=/Users/tml/android-ndk-r7b
|
|
--with-android-sdk=/Users/tml/android-sdk-macosx
|
|
--build=x86_64-apple-darwin11
|
|
--disable-zenity
|
|
--enable-werror
|
|
--with-distro=LibreOfficeAndroid
|
|
--disable-python
|
|
--without-helppack-integration
|
|
--without-myspell-dicts
|
|
--with-java
|
|
|
|
And here is an autogen.lastrun for Android when cross-compiling from Linux:
|
|
|
|
CC_FOR_BUILD=ccache gcc
|
|
CXX_FOR_BUILD=ccache g++
|
|
--with-android-ndk=/home/tml/android-ndk-r7b
|
|
--with-android-sdk=/home/tml/android-sdk-linux_x86
|
|
--with-ant-home=/opt/apache-ant-1.8.2
|
|
--build=x86_64-unknown-linux-gnu
|
|
--disable-zenity
|
|
--with-distro=LibreOfficeAndroid
|
|
--disable-python
|
|
--with-num-cpus=1
|
|
--with-max-jobs=1
|
|
--without-helppack-integration
|
|
--without-myspell-dicts
|
|
|
|
There is no interactive end-user "app" you could run yet that would
|
|
use LibreOffice code, but you can build some non-interactive unit
|
|
tests and run them on the emulator (or, presumably, on a device,
|
|
although that hasn't been tested as nobody with an actual Android
|
|
device has worked on it yet...) The simple unit tests will succeed,
|
|
the complex one still fails.
|
|
|
|
These unit tests *are* proper "apps" from Android'd point of view, but
|
|
they don't have any GUI and thus don't take part in the normal Android
|
|
message passing and Android thinks they are stuck and offers to kill
|
|
them...
|
|
|
|
The activity used for these apps is in android/Bootstrap. See
|
|
README.Android.
|
|
|
|
To build the complex unit test (for Calc functionality; invokes the
|
|
"ucalc" unit test code from sc) setup your environment (make cmd cmd=bash)
|
|
and cd to android/qa/sc and run a "make". The Makefile here is
|
|
completely manually written, this stuff is so experimental it doesn't
|
|
make sense yet to try to integrate with the normal gbuild
|
|
mechanism.
|
|
|
|
Then to run the unit test, do "make install" followed by "make
|
|
run". You most likely want to have an "adb logcat" running in another
|
|
window, and you probably also want to have set the stdout and stderr
|
|
of app processes to be redirected to logcat ("adb shell stop; adb
|
|
shell setprop log.redirect-stdio true; adb shell start").
|
|
|
|
To debug, do manually what "make run" would do, adding args "-e
|
|
lo-main-delay 20" to the command line, and when the app has started,
|
|
run ndk-gdb. Unfortunately the gdb in NDK r7 is broken, use the one in
|
|
the NDK build with newer versions of gcc and gdb from
|
|
http://code.google.com/p/mingw-and-ndk/ instead.
|
|
|
|
Running strace on the unit test in progress is often useful to find
|
|
out what is going wrong. Pass something like -e lo-strace '-tt -f -e
|
|
trace=file,process,network -o /system/sc/strace.out' to the am start
|
|
command line.
|
|
|
|
|
|
PowerPC Mac OS X
|
|
----------------
|
|
|
|
Cross-compiling for PowerPC Mac OS X from Intel Mac OS X will probably
|
|
be easy. The APIs available should after all be closely identical to
|
|
those on Intel Mac OS X, and LibreOffice builds fine natively on
|
|
PowerPC Mac already. Only a little experimenting has been done with
|
|
it. An autogen.lastrun looks like this:
|
|
|
|
CC=ccache /Xcode3/usr/bin/gcc-4.0 -arch ppc
|
|
CXX=ccache /Xcode3/usr/bin/g++-4.0 -arch ppc
|
|
CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0
|
|
CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0
|
|
--build=i386-apple-darwin10.7.0
|
|
--host=powerpc-apple-darwin10
|
|
--disable-mozilla
|
|
--disable-build-mozilla
|