|
|
| (28 intermediate revisions by 8 users not shown) |
| Line 1: |
Line 1: |
| − | [[Category:Development]]
| + | #REDIRECT [[Documentation/Building Guide]] |
| − | [[Category:Build_System]]
| + | |
| − | | + | |
| − | These are the instructions on how to build "vanilla" (or "up-stream") OpenOffice.org. Vanilla means: without tools like ooo-build that wrap the build-process. If you're using ooo-build, have a look at [[Building_with_ooobuild]] instead.
| + | |
| − | | + | |
| − | = Compiling OpenOffice.org : the practice =
| + | |
| − | == Getting the sources ==
| + | |
| − | To not make these instructions longer than necessary, there is a dedicated page on [[Getting_It | how to get the source]].
| + | |
| − | | + | |
| − | == Dependencies ==
| + | |
| − | Of course you need to have some development libraries installed to build OpenOffice.org.
| + | |
| − | The configure script will complain if something is missing.
| + | |
| − | Until this guide lists the prerequisites, please have a look at http://tools.openoffice.org/
| + | |
| − | | + | |
| − | ==Different Platforms==
| + | |
| − | Some information for specific platforms is provided at [http://tools.openoffice.org#Build tools].
| + | |
| − | | + | |
| − | Also for Mac OS X see [[AquaBuild]] ( experimental Aqua version of OpenOffice.org) or [[MacOSXBuildInstructions]] ( X11 version ), for GNU/Linux Sparc see [[GNULinuxSparcPorting]] and for Windows see [[Windows]].
| + | |
| − | | + | |
| − | = Building a Milestone =
| + | |
| − | == Running configure ==
| + | |
| − | The first step after getting the sources (and hopefully all prerequisites) is to run configure:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | cd <SRC_ROOT>
| + | |
| − | cd config_office
| + | |
| − | ./configure
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | You will most likely have to tell configure where it finds some packages such as ant or tell it what java to use. Use
| + | |
| − | <pre>
| + | |
| − | ./configure --help
| + | |
| − | </pre>
| + | |
| − | to get a list of valid options that you can use.
| + | |
| − | | + | |
| − | If you forgot to install some dependencies, the configure will remind you
| + | |
| − | which one are lacking.
| + | |
| − | | + | |
| − | Special hint related to ant: Make sure to use an absolute path.
| + | |
| − | | + | |
| − | == Bootstrapping ==
| + | |
| − | When configure ran fine (i.e. it did finish without any error or warnings), you can continue the build.
| + | |
| − | Configure creates an environment file that you need to read into your shell.
| + | |
| − | If you run bash, use
| + | |
| − | <pre>
| + | |
| − | cd <SRC_ROOT>
| + | |
| − | source LinuxX86Env.Set.sh
| + | |
| − | </pre>
| + | |
| − | If you run a tcsh or similar, use
| + | |
| − | <pre>
| + | |
| − | cd <SRC_ROOT>
| + | |
| − | source LinuxX86Env.Set
| + | |
| − | rehash
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Note: the environment script filename might be different on a different architecture. Replace 'X86' by what is appropriate. Also note that on older version it is 'Intel' and not 'X86'.
| + | |
| − | | + | |
| − | The last step before the real build is to build the buildtools that OOo uses. To do so, simply run
| + | |
| − | <pre>
| + | |
| − | ./bootstrap
| + | |
| − | </pre>
| + | |
| − | in <SRC_ROOT>
| + | |
| − | | + | |
| − | == Starting the real build ==
| + | |
| − | Now it is time for the real build
| + | |
| − | Just type
| + | |
| − | <pre>
| + | |
| − | dmake
| + | |
| − | </pre>
| + | |
| − | in <SRC_ROOT> and then relax.
| + | |
| − | Building OOo takes some time (approx 10-12 hours on standard desktop PC) so you can do other things in the meantime.
| + | |
| − | ==== Hints ====
| + | |
| − | dmake first proofs the depencies of the modules. If you have a fresh checkout you could get some errors:
| + | |
| − | <pre>
| + | |
| − | Fetching dependencies for module swext from solver... failed...
| + | |
| − | Fetching from CVS... failed
| + | |
| − | | + | |
| − | WARNING! Project(s):
| + | |
| − | swext
| + | |
| − |
| + | |
| − | not found and couldn't be built. Dependencies on that module(s)
| + | |
| − | ignored. Maybe you should correct build
| + | |
| − | dmake: Error code 1, while making 'check_modules'
| + | |
| − | </pre>
| + | |
| − | You have to checkout the module swext by i.e.:<br />
| + | |
| − | cvs co -r DEV300_m16 swext<br />
| + | |
| − | (for DEV300_m16)<br />
| + | |
| − | There are also failing depencies for modules apache-commons and tomcat. Check them out in the same way as swext above.<br />
| + | |
| − | If you get the following error or something similar:
| + | |
| − | <pre>
| + | |
| − | ERROR: /usr/lib/libcairo.so.2: undefined symbol: FT_Library_SetLcdFilter<br />
| + | |
| − | dmake: Error code 1, while making '../unxlngi6.pro/lib/libeggtrayli.so'
| + | |
| − | </pre>
| + | |
| − | your version of libcairo is to old. To solve this error install a newer version (i.e. libcairo.so.2.11.7).
| + | |
| − | When building with cairo, you almost certainly need to specify
| + | |
| − | --with-sytem-freetype, since the that is in OOo's sources just is too
| + | |
| − | old.<br />
| + | |
| − | There are actual an error about ant, if you build swext/mediawiki:
| + | |
| − | <pre>
| + | |
| − | BUILD FAILED
| + | |
| − | swext/mediawiki/build.xml:126: No supported regular expression matcher found: java.lang.ClassNotFoundException: org.apache.tools.ant.util.regexp.Jdk14RegexpMatcher
| + | |
| − | </pre>
| + | |
| − | This error could be solved on Linux by installing a package called ant-optional or similar. There are some additional files for ant missing.
| + | |
| − | | + | |
| − | = Building a [[CWS]] =
| + | |
| − | In order to build a child workspace (CWS), you need to first checkout the milestone that the cws is based upon (see Getting the source above). After that, you have to update the modules included in the cws with the cvs tag of the CWS.
| + | |
| − | | + | |
| − | You can either use [[EIS]] to get information about what milestone is the base for the CWS (see the field "Milestone (current)") and what modules it includes (see the table "Modules & Files") - or you can use [http://go-oo.org/tinderbox/tags/tag-list Tinderbox's tag-list] to get this information.
| + | |
| − | | + | |
| − | Once you have collected the necessary information, you can run:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | cd <SRC_ROOT>
| + | |
| − | setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
| + | |
| − | cvs [optional cvs flags such as -z #] update -dP -r <cwstag> <module1> <module2> <moduleN>
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Where
| + | |
| − | * SRC_ROOT is the top-level directory of your milestone-checkout
| + | |
| − | * cwstag is the cvs tag of the CWS. The tag is in the form cws_<main codeline>_<name of cws>, for example cws_src680_chart2mst3
| + | |
| − | | + | |
| − | Note: If you're using cvs using the ssh-tunnel, use ssh's compression rather than cvs compression - that gives better results
| + | |
| − | | + | |
| − | For example, you can issue :
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | cd src680-m172
| + | |
| − | setenv CVSROOT ":pserver:anoncvs@anoncvs.services.openoffice.org:/cvs"
| + | |
| − | cvs -z3 update -dP -r cws_src680_chart2mst3 chart2/ offuh/
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | = Tips and Tricks =
| + | |
| − | | + | |
| − | Here are some tips that make your life easier or can accelerate the build
| + | |
| − | | + | |
| − | == ccache ==
| + | |
| − | If possible, it is strongly recommended to install (and configure) [http://ccache.samba.org/ ccache] - this will greatly reduce build time on subsequent builds. Allow for a big cache and lots of files for the entire OOo build tree. If you're working on several [[CWS]]s simultaneously it pays to have separate caches, and also separate caches for non-/product builds within one CWS, e.g. after having sourced the environment execute the commands
| + | |
| − | | + | |
| − | export CCACHE_DIR="${YOUR_SOURCES}/$CWS_WORK_STAMP/.ccache_$INPATH"
| + | |
| − | ccache -M 2G -F 100000
| + | |
| − | export CC="ccache gcc"
| + | |
| − | export CXX="ccache g++"
| + | |
| − | | + | |
| − | in bash, respectively in tcsh
| + | |
| − | | + | |
| − | setenv CCACHE_DIR "${YOUR_SOURCES}/$CWS_WORK_STAMP/.ccache_$INPATH"
| + | |
| − | ccache -M 2G -F 100000
| + | |
| − | setenv CC "ccache gcc"
| + | |
| − | setenv CXX "ccache g++"
| + | |
| − | | + | |
| − | For Windows: download from [http://artax.karlin.mff.cuni.cz/~kendy/ccache/ here], do the following:
| + | |
| − | | + | |
| − | export CCACHE_DIR="some/place/with/space"
| + | |
| − | ccache -M 2G -F 10000
| + | |
| − | export CCACHE_CPP2=TRUE
| + | |
| − | export CXX="guw.pl ccache cl"
| + | |
| − | # export USE_PCH= if you experience trouble with precompiled headers
| + | |
| − | | + | |
| − | in bash, respectively in 4NT:
| + | |
| − | | + | |
| − | set CCACHE_DIR="some/place/with/space"
| + | |
| − | ccache -M 2G -F 10000
| + | |
| − | set CXX=ccache cl
| + | |
| − | unset USE_PCH
| + | |
| − | # if you want to experient with precompiled headers (not recommended):
| + | |
| − | set CCACHE_CPP2=TRUE and keep USE_PCH=TRUE
| + | |
| − | | + | |
| − | See also this [http://www.nabble.com/ccache-for-MSVC-t4013218.html thread] for background info on Windows ccache specifics.
| + | |
| − | | + | |
| − | == set nodep=TRUE ==
| + | |
| − | If you set the environment variable nodep to TRUE, then dependendy information files are not created - the build finishes faster.
| + | |
| − | | + | |
| − | But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.
| + | |
| − | | + | |
| − | == set NO_HIDS=TRUE ==
| + | |
| − | Similar to the nodep variable, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.
| + | |
| − | | + | |
| − | == use parallel builds ==
| + | |
| − | If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile level, the other one on module level
| + | |
| − | | + | |
| − | === set MAXPROCESS=<numer or processes> ===
| + | |
| − | This is the makefile-parallelism. This tells dmake how many targets it is allowed to build in parallel
| + | |
| − | | + | |
| − | === running parallel build.pl ===
| + | |
| − | For parallelism on the module level, you have to run build from <SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:
| + | |
| − | <pre>
| + | |
| − | build -P2
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | == create prebuilt mozilla and use that instead of recompiling everytime ==
| + | |
| − | For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages ([http://tools.openoffice.org/moz_prebuild/680/ the "official" ones can be obtained from tools.openoffice.org]) or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed)
| + | |
| − | You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself).
| + | |
| − | To do so:
| + | |
| − | | + | |
| − | * build the <code>moz</code> module from the mozilla sources<br/>(use <code>--enable-build-mozilla</code> when running configure and put the mozilla-source tarball to <code>moz/download</code>)
| + | |
| − | * in <code>moz</code> run <code>dmake zip</code> to create the zip files
| + | |
| − | * you'll find the zips in <code>{unxlngi#,wntmsci#}.pro/zipped</code>
| + | |
| − | | + | |
| − | Copy them to a location of your liking.
| + | |
| − | Now instead of using <code>--enable-build-mozilla</code>, use <code>--disable-build-mozilla</code> and copy the zips you created or downloaded to <code>moz/zipped</code> and these will be used when compiling.
| + | |
| − | This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla)
| + | |
| − | | + | |
| − | == saving disk space by linking to the solver only ==
| + | |
| − | Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:
| + | |
| − | <pre>
| + | |
| − | build --dlv_switch -link
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | == fixing epm 4 product name error ==
| + | |
| − | If you get "epm: Product names can only contain letters and numbers!" error, you must patch epm and comment out name check:
| + | |
| − | <pre>
| + | |
| − | /*
| + | |
| − | * for (i = 0; prodname[i]; i ++)
| + | |
| − | * if (!isalnum(prodname[i] & 255))
| + | |
| − | * {
| + | |
| − | * puts("epm: Product names can only contain letters and numbers!");
| + | |
| − | * usage();
| + | |
| − | * }
| + | |
| − | */
| + | |
| − | </pre>
| + | |
