diff options
Diffstat (limited to 'README.cross')
| -rw-r--r-- | README.cross | 271 |
1 files changed, 271 insertions, 0 deletions
diff --git a/README.cross b/README.cross new file mode 100644 index 000000000000..640b63055cc3 --- /dev/null +++ b/README.cross @@ -0,0 +1,271 @@ +Cross-compiling LibreOffice +=========================== + +Notes on cross-compiling LibreOffice, written by Tor Lillqvist +<tlillqvist@novell.com> <tml@iki.fi> in May, 2011. + +Cross-compilation of LibreOffice is not possible yet. Some initial +work is done, "baby steps", but a lot remains. This work is highly +experimental and done mostly in my own 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. + +My cross-compilation experimentation is going on for four platforms: +Windows, iOS, Android and PowerPC Mac OS X. I work on the master +branch of LibreOffice. Some other people have talked about setting up +a separate branch for Android work, or even separate clones at +github. I am not interested in that. + + +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, some more details might be needed. 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 but with the GNU tool-chain, i.e. what +is commonly known as MinGW. But as far as I know, 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 I have not attempted to check that it keeps +working. Ditto for native MinGW; if one compiles natively on Windows, +why not use Microsoft's compiler, as OOo/LO has been build for Windows +all the time using that and it works fine. + +In my opinion, 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 +and openSUSE. Personally I use the mingw32 packages in the openSUSE +Build Service, running on openSUSE: + +http://download.opensuse.org/repositories/windows:/mingw:/win32/ + +[You can install it like: + +zypper ar http://download.opensuse.org/repositories/windows:/mingw:/win32/SLE_11_SP1/windows:mingw:win32.repo +zypper in mingw32-cross-gcc mingw32-python-devel mingw32-libexpat-devel \ + mingw32-libexpat mingw32-boost-devel mingw32-libhyphen-devel \ + mingw32-libhyphen mingw32-hyphen-en mingw32-liblpsolve-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 is somewhat unclear how well thought-out the conditionals and code +for MinGW inside the OOo-originated code in LibreOffice actually +is. The little I have seen of it seems a bit randomish, with +copy-pasting having been preferred to factoring out differences. + +The autogen.lastrun I use for my MinGW cross-compilation experimentation is: + +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-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-zenity +--enable-python=system +--with-external-tar=/mnt/hemulen/ooo/git/master/src +--with-num-cpus=1 +--with-max-jobs=1 +--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-libxslt +--with-system-lpsolve +--with-system-mythes +--with-system-neon +--with-system-openssl +--with-system-redland +--with-vendor=no + + +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) to design a +touch GUI for LibreOffice, so the work on cross-compiling LibreOffice +for iOS is extremely experimental, and of course partly pointless;) +But it is interesting and fun nonetheless. + +Obviously it will make sense to build only a part of LibreOffice's +code for iOS. Most likely all GUI-oriented code should be left out, +and some iOS app 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. As I said, this is +highly experimental and just in its baby steps phase. + +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 MacOSX, 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 MacOSX (.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 +MacOSX, so that is where I have been doing it. + +Here is my autogen.lastrun for iOS (device): +CXX=ccache /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk +CC=ccache /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk +CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 +CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 +--with-distro=LibreOfficeiOS +--with-external-tar=/Volumes/ooo/git/master/src +--with-num-cpus=1 +--with-max-jobs=1 + +And here for the iOS simulator: +CXX=ccache /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/g++-4.2 -arch i386 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk +CC=ccache /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.2 -arch i386 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk +CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 +CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 +--with-distro=LibreOfficeiOS +--with-external-tar=/Volumes/ooo/git/master/src +--with-num-cpus=1 +--with-max-jobs=1 +--disable-librsvg +--enable-debug + + +Android +------- + +I don't know much about Android, but from a technical point of view it +is a kind of Linux, of course. As far as I know it is allowed for an +Android app to use shared objects, but if it isn't, then just the same +approach as used on iOS will need to be used. + +As for the GUI, the same holds as said above for iOS. + +I have done my Android cross-compilation work on Linux (openSUSE in +particular), but it could as well be done on MacOSX. The Android +cross-buld tool-chain (the "Native Development Kit", or NDK) is +available for Linux, MacOSX and Windows. (Trying to cross-compile from +Windows will probably drive you insane.) + +Here is my autogen.lastrun for Android: +SYSBASE=/home/tml/android-ndk-r5c/platforms/android-9/arch-arm +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 +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 +AR=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ar +NM=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-nm +OBJDUMP=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-objdump +RANLIB=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ranlib +STRIP=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip +CC_FOR_BUILD=ccache gcc +CXX_FOR_BUILD=ccache g++ +--build=x86_64-unknown-linux-gnu +--disable-zenity +--with-distro=LibreOfficeAndroid +--with-external-tar=/mnt/hemulen/ooo/git/master/src +--disable-python +--with-num-cpus=1 +--with-max-jobs=1 + + +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. I have just started experimenting with it. My +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 +--with-external-tar=/Volumes/ooo/git/master/src + + + +That's all, thank you, and have a nice day. People with commit access, +feel free to edit this document, and add yourself below. Sorry for +writing now initially from such a personal point of view. + +--Tor Lillqvist <tlillqvist@novell.com>, <tml@iki.fi> |