Difference between revisions of "Documentation/Building Guide/Building on Windows with MinGW"
m (→configure settings tips: l.c.e.) |
|||
(23 intermediate revisions by 11 users not shown) | |||
Line 6: | Line 6: | ||
{{DISPLAYTITLE:Building on Windows with MinGW}} | {{DISPLAYTITLE:Building on Windows with MinGW}} | ||
[[Category:Windows]] | [[Category:Windows]] | ||
+ | {{DraftPage|EN}} | ||
__TOC__ | __TOC__ | ||
Line 11: | Line 12: | ||
= Overview = | = Overview = | ||
− | {{ | + | {{Win| This document explains how to build the OpenOffice.org source code on Windows systems with MinGW compiler and linker.}} |
− | == | + | == What is MinGW? == |
MinGW stands for Minimalist’s GNU for Windows. It is a set of firee, open source software including compiler, linker,shell environment and other useful tools for developing software. MinGW is intended to support developing software to work on Microsoft 32-bit Windows with minimal support of external libraries. The MinGW community is distributing the g++ compiler from gcc (GNU compiler collection) and GNU ld linker for Windows 32-bit executables in GNU binutils, which is a set of tools to manipulate binary object and executable files. | MinGW stands for Minimalist’s GNU for Windows. It is a set of firee, open source software including compiler, linker,shell environment and other useful tools for developing software. MinGW is intended to support developing software to work on Microsoft 32-bit Windows with minimal support of external libraries. The MinGW community is distributing the g++ compiler from gcc (GNU compiler collection) and GNU ld linker for Windows 32-bit executables in GNU binutils, which is a set of tools to manipulate binary object and executable files. | ||
+ | |||
+ | == The reason why MinGW build is being maintained == | ||
+ | Please note the official releases of OpenOffice.org for Windows are built using tools from Microsoft. The build with MinGW compiler and linker is being maintained for checking the code portability and keeping the alternative to Microsoft tools. Microsoft compiler does not complain at some codes violating C++ standard and although Microsoft is supplying Visual Studio Express edition free of charge for the time being, they may stop to do so in the future. And it may make sense to keep OOo to be buildable with open source tools. | ||
== Cygwin == | == Cygwin == | ||
− | For building OpenOffice.org Cygwin is needed, a Windows program that emulates a complete Unix command line environment. To use this document you need to be familiar with a command line, but you need not to be a UNIX shell wizard. | + | For building OpenOffice.org, Cygwin is needed, a Windows program that emulates a complete Unix command-line environment. To use this document, you need to be familiar with a command line, but you need not to be a UNIX shell wizard. |
− | {{ | + | {{Tip|If you have never used a Unix shell, you might want to take a look at the [http://tldp.org/LDP/GNU-Linux-Tools-Summary/html/index.html shell introduction at TLDP].}} |
− | {{ | + | {{Note|<tt>$SRC_ROOT</tt> will denote the directory in which the source code of OpenOffice.org is stored.}} |
− | {{ | + | {{Tip|You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases.}} |
− | == Cygwin compiler | + | == Cygwin compiler vs. MinGW compiler == |
− | Cygwin also includes C++ compiler and linker in its distribution as well as headers and libraries of MinGW. Specifying -mno-cygwin command line switch, the tools can generate the same object code to MinGW compiler. However, as the tools use Cygwin system call to invoke sub programs, the process to build OpenOffice.org with Cygwin’s compiler and linker is a bit slower and more unstable than that with “pure” MinGW tools on Cygwin shell. | + | Cygwin also includes C++ compiler and linker in its distribution, as well as headers and libraries of MinGW. Specifying -mno-cygwin command line switch, the tools can generate the same object code to MinGW compiler. However, as the tools use Cygwin system call to invoke sub programs, the process to build OpenOffice.org with Cygwin’s compiler and linker is a bit slower and more unstable than that with “pure” MinGW tools on Cygwin shell. |
− | == | + | |
+ | == Versions and problems in compiler and linker == | ||
The version of the official release of gcc from MinGW is gcc-3.4.5 for version 3 series and gcc-4.4.0 for version 4 series. 4.4.0 is the first official release of version 4 series and older versions in version 4 series were all experimental. Cygwin includes gcc-3.4.4 and experimental 4.3.2. | The version of the official release of gcc from MinGW is gcc-3.4.5 for version 3 series and gcc-4.4.0 for version 4 series. 4.4.0 is the first official release of version 4 series and older versions in version 4 series were all experimental. Cygwin includes gcc-3.4.4 and experimental 4.3.2. | ||
Compilers of version 3 series have several problems to build OOo and needs patches. You can get the patched binaries of core C compiler and C++ compiler at [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW ooopackages.good-day.net]. Available version is only 3.4.4. The source patch is also available there. You can get the patched compilers equivalent to them in Cygwin distribution. You have to get core C compiler, C++ compiler and the MinGW libraries for both C and C++ at [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW ooopackages.good-day.net]. Please note that you have to run the postinstall command in /etc/postinstall directory after extracting the distribution of both of the MinGW libraries for C on Cygwin and that for C++ under root directory in Cygwin command prompt. | Compilers of version 3 series have several problems to build OOo and needs patches. You can get the patched binaries of core C compiler and C++ compiler at [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW ooopackages.good-day.net]. Available version is only 3.4.4. The source patch is also available there. You can get the patched compilers equivalent to them in Cygwin distribution. You have to get core C compiler, C++ compiler and the MinGW libraries for both C and C++ at [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW ooopackages.good-day.net]. Please note that you have to run the postinstall command in /etc/postinstall directory after extracting the distribution of both of the MinGW libraries for C on Cygwin and that for C++ under root directory in Cygwin command prompt. | ||
Line 32: | Line 37: | ||
Gcc version 4 emits better code and useful warning messages. However, you should concern licence agreements of dlls. MinGW gcc compiler has restriction to use dynamic linking of the two library libgcc and libstdc++ for proper exception handling and the dlls will be included in the installation set you will build. In the meantime the licence agreements of these dlls have a rather strict term to follow if you redistribute them. | Gcc version 4 emits better code and useful warning messages. However, you should concern licence agreements of dlls. MinGW gcc compiler has restriction to use dynamic linking of the two library libgcc and libstdc++ for proper exception handling and the dlls will be included in the installation set you will build. In the meantime the licence agreements of these dlls have a rather strict term to follow if you redistribute them. | ||
The version of the official release of binutils from both MinGW and Cygwin is 2.19.18 and ld linker has problems to build OOo. The patched binaries and sources are available at [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW ooopackages.good-day.net]. | The version of the official release of binutils from both MinGW and Cygwin is 2.19.18 and ld linker has problems to build OOo. The patched binaries and sources are available at [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW ooopackages.good-day.net]. | ||
+ | |||
== w32api and MinGW runtime library == | == w32api and MinGW runtime library == | ||
The set of libraries and headers to let code to use Windows API is distributed as w32api. The version 3.13 is required for building OOo. Some new APIs and constant definitions that are not officially published from Microsoft are not included and you have to use files in Microsoft SDK with smalll patches. MinGW runtime library of version 3.16 is required as well to enable multithreading and fix some C functions. MinGW tools are intended to use Microsoft C runtime library that is always installed in Windows system but some bugs are fixed in MinGW runtime library. | The set of libraries and headers to let code to use Windows API is distributed as w32api. The version 3.13 is required for building OOo. Some new APIs and constant definitions that are not officially published from Microsoft are not included and you have to use files in Microsoft SDK with smalll patches. MinGW runtime library of version 3.16 is required as well to enable multithreading and fix some C functions. MinGW tools are intended to use Microsoft C runtime library that is always installed in Windows system but some bugs are fixed in MinGW runtime library. | ||
+ | |||
= Requirements = | = Requirements = | ||
− | == | + | == Hardware requirements == |
* 1 or more reasonable fast CPUs (x-way CPU recommended) | * 1 or more reasonable fast CPUs (x-way CPU recommended) | ||
Line 41: | Line 48: | ||
* 10 GB free disk space (20 GB when debugging) | * 10 GB free disk space (20 GB when debugging) | ||
− | == | + | == Software requirements == |
* Windows XP/Vista | * Windows XP/Vista | ||
Line 56: | Line 63: | ||
|- | |- | ||
| Either of | | Either of | ||
− | “pure” gcc 3 series tools including patched “pure” MingW gcc 3 compiler and patched binutils: [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW/misc/tools gcc-core-3.4.4-20050522-1-ooopatched.tar.gz gcc-g++-3.4.4-20050522-1-ooopatched.tar.gz binutils-2. | + | “pure” gcc 3 series tools including patched “pure” MingW gcc 3 compiler and patched binutils: [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW/misc/tools gcc-core-3.4.4-20050522-1-ooopatched.tar.gz gcc-g++-3.4.4-20050522-1-ooopatched.tar.gz binutils-2.20.1-ooopatched.tar.gz] and w32api and MinGW runtime: [http://sourceforge.net/projects/mingw/files/ w32api-3.13-mingw32-dev.tar.gz mingwrt-3.16-mingw32-dev.tar.gz mingwrt-3.16-mingw32-dll.tar.gz] or |
− | “pure” gcc 4 series tools including patched binutils and the library rebuilding script: [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW/misc/tools binutils-2. | + | “pure” gcc 4 series tools including patched binutils and the library rebuilding script: [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW/misc/tools binutils-2.20.1-ooopatched.tar.gz gcc-core-g++-4.4.0-install.sh] and MingW gcc 4 compiler, w32api and MinGW runtime: [http://sourceforge.net/projects/mingw/files/ gcc-core-4.4.0-mingw32-bin.tar.gz gcc-core-4.4.0-mingw32-dll.tar.gz gcc-c++-4.4.0-mingw32-bin.tar.gz gcc-c++-4.4.0-mingw32-dll.tar.gz gmp-4.2.4-mingw32-dll.tar.gz mpfr-2.4.1-mingw32-dll.tar.gz pthreads-w32-2.8.0-mingw32-dll.tar.gz w32api-3.14-mingw32-dev.tar.gz mingwrt-3.18-mingw32-dev.tar.gz mingwrt-3.18-mingw32-dll.tar.gz] or |
− | Cygwin tools including patched Cygwin gcc 3 compiler and patched binutils (w32api and MinGW runtime for Cygwin compiler/linker are included in Cygwin distribution): [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW/misc/tools/cygwin gcc-core-3.4.4-3ooopatched.tar.bz2 gcc-g++-3.4.4-3ooopatched.tar.bz2 gcc-mingw-core-20050522-ooopatched-1.tar.bz2 gcc-mingw-g++-20050522-ooopatched-1.tar.bz2 binutils- | + | Cygwin tools including patched Cygwin gcc 3 compiler and patched binutils (w32api and MinGW runtime for Cygwin compiler/linker are included in Cygwin distribution): [ftp://ooopackages.good-day.net/pub/OpenOffice.org/Windows/MinGW/misc/tools/cygwin gcc-core-3.4.4-3ooopatched.tar.bz2 gcc-g++-3.4.4-3ooopatched.tar.bz2 gcc-mingw-core-20050522-ooopatched-1.tar.bz2 gcc-mingw-g++-20050522-ooopatched-1.tar.bz2 binutils-2.20.51-2-ooopatched.tar.bz2] |
| (default) | | (default) | ||
|- | |- | ||
Line 66: | Line 73: | ||
| (default) | | (default) | ||
|- | |- | ||
− | | [http://www.microsoft.com/downloads/details.aspx?FamilyId=F26B1AA4-741A-433A-9BE5-FA919850BDBF&displaylang=en Windows SDK for Windows Server 2008]. < | + | | [http://www.microsoft.com/downloads/details.aspx?FamilyId=F26B1AA4-741A-433A-9BE5-FA919850BDBF&displaylang=en Windows SDK for Windows Server 2008].<ref name="Foot1">{{Template:Note|This also supported on Vista. This is either a DVD image or a net installer. You can either mount the DVD with a suitable tool, burn it do a DVD or use tools like winrar that can extract files from ISO files directly. You don't need to install samples or documentation (saves a lot of disk space). It will also install the .NET Framework 3.5 SDK. |
+ | It might be best to install the Windows SDK into the default directory, and if not that into one without capital letters in the path. I used D:\Dev\Win_SDK\ and received some linking errors in the Python module (see {{Bug|88568}}).}}</ref> | ||
| | | | ||
|- | |- | ||
Line 72: | Line 80: | ||
| external/gdiplus | | external/gdiplus | ||
|- | |- | ||
− | | Only for OOo2.x but due to {{Bug|88652}} in configure still needed for 3.x: [http://download.microsoft.com/download/b/7/5/b75eace3-00e2-4aa0-9a6f-0b6882c71642/unicows.exe unicows.dll from (Microsoft Layer for Unicode)] < | + | | Only for OOo2.x but due to {{Bug|88652}} in configure still needed for 3.x: [http://download.microsoft.com/download/b/7/5/b75eace3-00e2-4aa0-9a6f-0b6882c71642/unicows.exe unicows.dll from (Microsoft Layer for Unicode)]<ref name="Foot2">{{Note|unicows.dll is available from the Microsoft site and needs to be saved to $SRC_ROOT/external/unicows. Microsoft seems to enjoy changing the exact location of this file. You may have to search Microsoft's website.}}</ref> |
| external/unicows | | external/unicows | ||
|- | |- | ||
− | | [http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=CD1FC4B2-0885-47F4-AF45-7FD5E14DB6C0 dbghelp.dll] < | + | | [http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=CD1FC4B2-0885-47F4-AF45-7FD5E14DB6C0 dbghelp.dll]<ref name="Foot3">{{Note|dbghelp.dll is available from the Microsoft site and needs to be saved to $SRC_ROOT/external/dbghelp. Microsoft seems to enjoy changing the exact location of this file. You may have to search Microsoft's website.}}</ref> |
+ | |||
| external/dbghelp | | external/dbghelp | ||
|- | |- | ||
Line 88: | Line 97: | ||
| moz/zipped | | moz/zipped | ||
|- | |- | ||
− | | optional: [http://nsis.sourceforge.net/ Nullsoft Scriptable Install System (NSIS)]< | + | | optional: [http://nsis.sourceforge.net/ Nullsoft Scriptable Install System (NSIS)]<ref name="Foot5">{{Note|If NSIS is available, a self contained Windows installer is created in addition to the MSI installer files.}} |
+ | |||
+ | {{Warn|It used to be that newer version of NSIS broke the build (see {{Bug|85657}}), but it seems that it now works for NSIS up to 2.3.7.}}</ref> | ||
| | | | ||
|- | |- | ||
− | | optional: [http://msdn.microsoft.com/directx/directxdownloads/ Microsoft DirectX SDK]< | + | | optional: [http://msdn.microsoft.com/directx/directxdownloads/ Microsoft DirectX SDK]<ref name="Foot6">{{Note|If you don't want to download it you can disable DirectX support in the configuration step (<tt>--disable-directx</tt>).}} |
+ | |||
+ | {{Warn|Current (as of 2008/01) versions of the DirectX9 SDK and Windows Platform SDK do not fit to each other. To be able to build with DirextX enabled, you need to patch one file in the Platform SDK. See http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID2743771 for details.}} | ||
+ | |||
+ | {{Warn|Do not use a DirectX10 SDK!}}</ref> | ||
| | | | ||
|- | |- | ||
Line 97: | Line 112: | ||
| | | | ||
|} | |} | ||
− | |||
− | + | === Adding required files to the build tree === | |
− | {{ | + | {{Tip|Some of the files can be found in a suitable OOo installation set also, so you can save the download by “stealing” it from your OOo installation.}} |
+ | {{Note|OOo uses some Mozilla libraries. On Windows the Mozilla libraries are needed only for Mozilla address book support. Unfortunately a bug in the module dependencies makes it necessary that the Mozilla libaries are used anyway as otherwise building the module <tt>xmlsecurity</tt> fails (see below).}} | ||
− | = Installation and | + | = Installation and preparation of build tools = |
− | == | + | == Setting up cygwin == |
Go to http://www.cygwin.com/ and download and install the current version. | Go to http://www.cygwin.com/ and download and install the current version. | ||
− | {{ | + | {{Warn|Make sure that you keep the filetype set to “Unix/binary”.}} |
− | === | + | === Required additional packages === |
Cygwin consists of some basic and a lot of optional packages. As building OOo needs some of these optional packages you have to select them in the installer. | Cygwin consists of some basic and a lot of optional packages. As building OOo needs some of these optional packages you have to select them in the installer. | ||
Here's a complete list of the needed packages: | Here's a complete list of the needed packages: | ||
* Category Archive: | * Category Archive: | ||
+ | ** cabextract | ||
** unzip | ** unzip | ||
** zip | ** zip | ||
Line 124: | Line 140: | ||
** make | ** make | ||
** openssl-devel (only needed for perl modules for CWS tooling, see below) | ** openssl-devel (only needed for perl modules for CWS tooling, see below) | ||
+ | ** pkgconfig | ||
** cvs (for 2.x code line and 3.0 code line) | ** cvs (for 2.x code line and 3.0 code line) | ||
** subversion (for 3.x code line, minimum version 1.5.5) | ** subversion (for 3.x code line, minimum version 1.5.5) | ||
Line 131: | Line 148: | ||
** openssh | ** openssh | ||
** ncftp | ** ncftp | ||
+ | ** rsync | ||
* Category Perl | * Category Perl | ||
** perl | ** perl | ||
Line 142: | Line 160: | ||
** lynx | ** lynx | ||
** wget | ** wget | ||
− | {{ | + | {{Warn|You have to exclude the package rebase in Category Base if you use Cygwin compiler for OOo build.}} |
− | {{ | + | {{Note|Unfortunately the list of packages mentioned at http://website.openoffice.org/support/en/howtos/1.html#1 is incomplete, some more are listed at http://tools.openoffice.org/dev_docs/build_windows_tcsh.html#BuildRequirements .}} |
− | {{ | + | {{Note|The installer will automatically check and download some more packages needed by thosed listed here. The whole process takes roughly 20 minutes.}} |
− | === | + | === Breaking links to executables === |
Within the Cygwin Toolkit, some executables might be symlinks: awk.exe and gunzip.exe, tar.exe (in older releases only). This can lead to a break of the build later, and the symlinks should be replaced by copies of the command they link to. | Within the Cygwin Toolkit, some executables might be symlinks: awk.exe and gunzip.exe, tar.exe (in older releases only). This can lead to a break of the build later, and the symlinks should be replaced by copies of the command they link to. | ||
Line 161: | Line 179: | ||
− | In case you overlook something here or you have a newer Cygwin version with additional symlinks not mentioned here it's not a problem. You will get a helpful error message about an existing link in the configuration step (configure) later. The message will tell you which link you have to remove and you can do it following the advice given above for the awk.exe/gawk.exe pair. | + | In case you overlook something here or you have a newer Cygwin version with additional symlinks not mentioned here, it's not a problem. You will get a helpful error message about an existing link in the configuration step (configure) later. The message will tell you which link you have to remove, and you can do it following the advice given above for the awk.exe/gawk.exe pair. |
− | === | + | === Installing additional perl modules in cygwin === |
As explained some perl modules must be installed with CPAN. The necessary command in the cygwin shell is | As explained some perl modules must be installed with CPAN. The necessary command in the cygwin shell is | ||
perl -MCPAN -e shell | perl -MCPAN -e shell | ||
− | If this command is executed the first time CPAN will ask for configuration. Choose autoconfiguration. | + | If this command is executed, the first time CPAN will ask for configuration. Choose autoconfiguration. |
− | {{ | + | {{Warn|Please note that CPAN is not able to deal with usernames containing spaces. To work around this fact, when CPAN asks you to specify the ''CPAN build and cache directory'', change the default suggestion to <tt>/cpan</tt>.}} |
− | At the end the CPAN shell appeared and is ready to accept commands for installations. Each module is installed by typing < | + | At the end, the CPAN shell appeared and is ready to accept commands for installations. Each module is installed by typing <tt>install $MODULENAME</tt>. The modules that must be installed are: |
* Archive::Zip | * Archive::Zip | ||
Line 183: | Line 201: | ||
CPAN will detect if a selected module depends on other modules and it will offer to download them also. As explained please just confirm this. | CPAN will detect if a selected module depends on other modules and it will offer to download them also. As explained please just confirm this. | ||
− | {{ | + | {{Note|The last three modules are only needed if you want to use the cws tooling. These tools are necessary if you want to create and maintain your own [http://wiki.services.openoffice.org/wiki/CWS Child Workspaces] or if you want to build one of them. I recommend to install them anyway as sooner or later you want to work on a child workspace.}} |
− | {{ | + | {{Warn|I got an error message from CPAN somewhat like the following: |
<pre>C:\cygwin\bin\perl.exe: *** unable to remap C:\cygwin\bin\cygiconv-2.dll to same | <pre>C:\cygwin\bin\perl.exe: *** unable to remap C:\cygwin\bin\cygiconv-2.dll to same | ||
address as parent(0x7C0000) != 0x7D0000</pre> | address as parent(0x7C0000) != 0x7D0000</pre> | ||
− | To fix this, I had to exit the Cygwin shell, run cmd.exe, then type "c:\cygwin\bin\ash.exe" to start the minimal shell, then type < | + | To fix this, I had to exit the Cygwin shell, run cmd.exe, then type "c:\cygwin\bin\ash.exe" to start the minimal shell, then type <tt>/bin/rebaseall</tt>. Then CPAN worked when I ran it again.}} |
− | {{ | + | {{Warn| I got another error when cygwin was performing <tt>make install</tt>: |
<pre>ERROR: Can't create '/usr/bin'; Do not have write permissions on '/usr/bin'</pre> | <pre>ERROR: Can't create '/usr/bin'; Do not have write permissions on '/usr/bin'</pre> | ||
I can actually write to /usr/bin; however when I do <tt>ls -ld /usr/bin</tt>, cygwin reports no write permission; and <tt>chmod u+w /usr/bin</tt> gives <tt>Permission denied</tt>. This causes the install process to fail when it checks permissions. As a kludge, I installed vim, and edited line 368 of /usr/lib/perl5/5.10/ExtUtils/Install.pm, replacing this: | I can actually write to /usr/bin; however when I do <tt>ls -ld /usr/bin</tt>, cygwin reports no write permission; and <tt>chmod u+w /usr/bin</tt> gives <tt>Permission denied</tt>. This causes the install process to fail when it checks permissions. As a kludge, I installed vim, and edited line 368 of /usr/lib/perl5/5.10/ExtUtils/Install.pm, replacing this: | ||
Line 198: | Line 216: | ||
which allowed installation to proceed.}} | which allowed installation to proceed.}} | ||
− | == | + | == Installing compiler and binutils == |
− | === | + | === Installing “pure” MinGW gcc version 3 series compiler and binutils === |
To install “pure” MinGW gcc version 3 series compiler and binutils, you have to create a unique directory first, say <tt>c:/mingw</tt>. All you have to do is to extract all tarballs here. | To install “pure” MinGW gcc version 3 series compiler and binutils, you have to create a unique directory first, say <tt>c:/mingw</tt>. All you have to do is to extract all tarballs here. | ||
tar -C c:/mingw -xvzpf xxx.tar.gz | tar -C c:/mingw -xvzpf xxx.tar.gz | ||
− | === | + | === Installing “pure” MinGW gcc version 4 series compiler and binutils === |
To install “pure” MinGW gcc version 4 series compiler and binutils, you have to choose a unique directory name, say <tt>c:/mingw</tt>, put everything you downloaded in one working directory and invoke the following command in the directory. | To install “pure” MinGW gcc version 4 series compiler and binutils, you have to choose a unique directory name, say <tt>c:/mingw</tt>, put everything you downloaded in one working directory and invoke the following command in the directory. | ||
./gcc-core-g++-4.4.0-install.sh c:/mingw | ./gcc-core-g++-4.4.0-install.sh c:/mingw | ||
− | === | + | Extend the path to get the right compiler: |
+ | |||
+ | export PATH=/cygdrive/c/mingw/bin:$PATH | ||
+ | |||
+ | === Installing Cygwin gcc version 3 series compiler and binutils === | ||
You have to extract all tarballs in root directory. | You have to extract all tarballs in root directory. | ||
Line 219: | Line 241: | ||
/etc/postinstall/gcc-mingw-g++.sh | /etc/postinstall/gcc-mingw-g++.sh | ||
− | = Full | + | = Full builds = |
== configure == | == configure == | ||
− | Finally the < | + | Finally the <tt>configure</tt> tool is used to create the environment. It checks that all software, hardware, and system requirements for the build are satisfied, and creates configuration files called winmingw.set (for tcsh) and winmingw.set.sh (for bash) that are used to set all necessary build environment variables. Before running configure, make sure that all needed programs are in the system path or start configure with the appropriate command line switches. If configure detects a problem it will stop and give you a useful hint how to fix it. |
− | You will find the < | + | You will find the <tt>configure</tt> script in <tt>$SRC_ROOT</tt>. The resulting configuration files are created there too. |
− | ==== | + | ==== Sample configure calls ==== |
./configure \ | ./configure \ | ||
Line 239: | Line 261: | ||
--with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" \ | --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" \ | ||
--with-ant-home=/ant \ | --with-ant-home=/ant \ | ||
− | |||
--with-mozilla-build=/cygdrive/c/mozilla-build/moztools \ | --with-mozilla-build=/cygdrive/c/mozilla-build/moztools \ | ||
--with-nsis-path=/cygdrive/c/PROGRA~1/NSIS | --with-nsis-path=/cygdrive/c/PROGRA~1/NSIS | ||
Line 254: | Line 275: | ||
--with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" \ | --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" \ | ||
--with-ant-home=/ant \ | --with-ant-home=/ant \ | ||
− | |||
--with-mozilla-build=/cygdrive/c/mozilla-build/moztools \ | --with-mozilla-build=/cygdrive/c/mozilla-build/moztools \ | ||
--with-nsis-path=/cygdrive/c/PROGRA~1/NSIS \ | --with-nsis-path=/cygdrive/c/PROGRA~1/NSIS \ | ||
Line 268: | Line 288: | ||
==== configure settings tips ==== | ==== configure settings tips ==== | ||
− | {{ | + | {{Warn|Make sure that the <tt>PATH</tt> variable in your cygwin shell does not contain any blanks and quotes.}} |
− | {{ | + | {{Warn|Paths might have problems with spaces. Install requirements into paths without them. Alternatively, feel free to install the various packages using the default path containing spaces and then use the mixed short path for the configure stage. The mixed short path can be obtained using Cygwin's cygpath tool, eg: |
<pre>$ cygpath -m -s "c:\Program Files\Microsoft SDKs" | <pre>$ cygpath -m -s "c:\Program Files\Microsoft SDKs" | ||
c:/PROGRA~1/MI2578~1</pre> | c:/PROGRA~1/MI2578~1</pre> | ||
− | The < | + | The <tt>with-psdk-home</tt> setting needs a case-sensitive path name. I recommend to use case-sensitive usage in all cases - it's good to get used to case sensitivity if you are going to work with Cygwin.}} |
− | {{ | + | {{Warn|Beware of using <tt>/c/</tt> instead of <tt>/cygdrive/c/</tt>.}} |
− | {{ | + | {{Warn|Avoid trailing slashes in configure parameters. They sure cause problems for <tt>--with-psdk-home</tt>.}} |
− | {{ | + | {{Note|Paths to dependencies might be different for your installation. The paths containing "msvc" and "msdk" should be self-explanatory.}} |
− | {{ | + | {{Tip|There are a number of options that you can use with the configure script. To display these options, type the following command: |
<pre>./configure --help</pre>}} | <pre>./configure --help</pre>}} | ||
− | {{ | + | {{Tip|If you run into problems with early DEV300 releases, check your settings in winmingw.set.sh for <tt>WINDOWS_VISTA_PSDK</tt> to be set <tt>TRUE</tt>. This is important if <tt>configure</tt> fails to detect the Windows platform SDK version correctly. The detection failure results from the way that <tt>configure</tt> searches for the Vista PSDK in older releases: it will be found only if it is installed into the default location.}} |
− | {{ | + | {{Tip|If you run into problems with early DEV300 releases, check your settings in winmingw.set.sh for <tt>DISABLE_ATL</tt>, <tt>DISABLE_ACTIVEX</tt>: all have to be set <tt>TRUE</tt>. If you want to build the OOo ActiveX control, OLE automation and native Windows OLE support, you have to copy atl headers from old release of Microsoft Platform SDK.}} |
− | {{ | + | {{Tip|As DirectX is not needed for most developers, its SDK consumes a lot of disk space and is prone to incompatibilities I recommend to build without DirecX support by using <tt>--disable-directx</tt> as shown above. Otherwise you have to provide the path to the SDK in <tt>--with-directx-home</tt>.}} |
− | {{ | + | {{Tip|OOo uses some Mozilla components. Disabling the Mozilla components completely with <tt>--disable-mozilla</tt> currently might not work due to a bug in the module dependencies.}} |
− | {{ | + | {{Tip|If you experiment with the newest sources, mind that it can happen sometimes that <tt>configure.in</tt> was updated, but it was forgotten to update configure too. The configure script itself is created from <tt>configure.in</tt> using the <tt>autoreconf</tt> command. The perl script <tt>set_soenv</tt> is created when you run configure from <tt>set_soenv.in</tt>.}} |
− | {{ | + | {{Tip|csc.exe comes from the <tt>c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322</tt> directory, you might need <tt>--with-csc-path</tt>.}} |
− | {{ | + | {{Tip|If you fail to getting together a working installation of Cygwin, one possibility is to use a known-to-work combination of Cygwin packages, i.e. a direct copy of some other user's Cygwin tree. [[User:TorLillqvist]] has such a tree (from late 2006) zipped up at http://download.go-oo.org/tstnvl/tml/tml-cygwin.zip . Don't hesitate to ask for advice if necessary.}} |
== bootstrap == | == bootstrap == | ||
Line 291: | Line 311: | ||
./bootstrap | ./bootstrap | ||
− | == | + | == Setting the environment == |
− | When the configure script has been run successfully a file < | + | When the configure script has been run successfully a file <tt>winmingw.Set.sh</tt> was created<ref name="Foot7">{{Note|When you want to use tcsh instead of bash, you will need to use the file <tt>winmingw.Set</tt> instead: |
+ | <pre> source winmingw.Set | ||
+ | rehash</pre> | ||
+ | If you do not use tcsh, it is better to delete that file, as it will get in the way for tab-completion sooner or later.}}</ref>. Do this: | ||
source winmingw.Set.sh | source winmingw.Set.sh | ||
− | to set up the | + | to set up the environment for the build. |
− | == | + | == Starting the build == |
− | Build the software by typing the following in < | + | Build the software by typing the following in <tt>$SRC_ROOT</tt> <ref name="Foot8">{{Template:Note|You can also run: |
+ | <pre>make</pre> | ||
+ | but GNU/make will just start dmake. You can also run the following in the <tt>instetoo_native</tt> module: | ||
+ | <pre>build --all</pre> | ||
+ | For details run: | ||
+ | <pre>build --help</pre>}}</ref>: | ||
dmake | dmake | ||
Line 307: | Line 335: | ||
There are some special things in the way how OOo builds its modules. Every module has an “output” folder (with some subfolders for the different kinds of generated output) that is created the first time a build is done in the module. The name of this folder is “wntgcci.pro” (for the meaning of the "pro" extension see below). After a successful build of a module some of the generated files are copied to the output folder of the “solver” module by executing a tool called “deliver” (this is automatically called by build --all for each of the modules). Other modules will take these “delivered” files (header files, libraries etc.) to resolve their dependencies. The content of the solver module will also be used to pack the installation sets in the final step. | There are some special things in the way how OOo builds its modules. Every module has an “output” folder (with some subfolders for the different kinds of generated output) that is created the first time a build is done in the module. The name of this folder is “wntgcci.pro” (for the meaning of the "pro" extension see below). After a successful build of a module some of the generated files are copied to the output folder of the “solver” module by executing a tool called “deliver” (this is automatically called by build --all for each of the modules). Other modules will take these “delivered” files (header files, libraries etc.) to resolve their dependencies. The content of the solver module will also be used to pack the installation sets in the final step. | ||
− | {{ | + | {{Tip|Using some not quite latest cygwin releases (1.5.18/1.5.19) can lead to tcsh freezing in places - the build will appear to hang. You can fix this by running ''ls /proc/$nnn/fd'' where $nnn is the number of the process. Or just run |
<pre>ls /proc/*/fd</pre> | <pre>ls /proc/*/fd</pre> | ||
to "unhang" the process. See {{Bug|51560}} for more info...}} | to "unhang" the process. See {{Bug|51560}} for more info...}} | ||
− | + | = Partial builds = | |
− | = Partial | + | |
There are two ways to do partial builds: | There are two ways to do partial builds: | ||
* compatible | * compatible | ||
* incompatible | * incompatible | ||
Only do compatible partial builds if you know exactly what you are doing. | Only do compatible partial builds if you know exactly what you are doing. | ||
− | {{ | + | {{Note|For more information, see [[Compatible Builds]].}} |
− | == | + | |
+ | == Rebuilding from a module (incompatible build) == | ||
If you decide to change a module in an incompatible way, you will need to rebuild all modules depending on it (directly or indirectly): | If you decide to change a module in an incompatible way, you will need to rebuild all modules depending on it (directly or indirectly): | ||
Line 326: | Line 354: | ||
build --from $INCOMPATIBLEMODULE | build --from $INCOMPATIBLEMODULE | ||
− | == | + | == Rebuilding a module (compatible build) == |
To rebuild a module you can delete all output directories with, rebuild and redeliver into the solver with: | To rebuild a module you can delete all output directories with, rebuild and redeliver into the solver with: | ||
Line 334: | Line 362: | ||
build && deliver | build && deliver | ||
− | A simple < | + | A simple <tt>build</tt> in <tt>$SRC_ROOT/instsetoo_native</tt> will recreate the installation sets, provided all other modules have already been build. <ref name="Foot9">{{Warn|<tt>build --all</tt> would rebuild changed/missing files. However, it does not check for incompatible modules. If unsure, use <tt>build --from --prepare</tt>.}}</ref> |
+ | |||
− | = Building a | + | = Building a module with debug information = |
To rebuild a module with debug information and additional assertions and checks, run: | To rebuild a module with debug information and additional assertions and checks, run: | ||
Line 346: | Line 375: | ||
Drop the newly created binaries into an existing installation. Building an installation set with them will not help, as binaries are stripped on packing by default. | Drop the newly created binaries into an existing installation. Building an installation set with them will not help, as binaries are stripped on packing by default. | ||
− | {{ | + | {{Tip|For details, see [[Windows Debugging]].}} |
− | = Finding the | + | = Finding the installation sets = |
After a successful build you will find the OOo installation set in | After a successful build you will find the OOo installation set in | ||
Line 354: | Line 383: | ||
“instsetoo_native” is the module that packs the installation set. | “instsetoo_native” is the module that packs the installation set. | ||
− | {{ | + | {{Tip|If you already have a version of OOo installed you can install your freshly built version in parallel by installing it with setup /a that just unpacks all files without any system registration.}} |
− | = Tips | + | = Tips and tricks = |
== ccache == | == ccache == | ||
For Windows: download from [http://artax.karlin.mff.cuni.cz/~kendy/ccache/ here], do the following: | For Windows: download from [http://artax.karlin.mff.cuni.cz/~kendy/ccache/ here], do the following: | ||
Line 365: | Line 394: | ||
export CXX="guw.pl ccache cl" | export CXX="guw.pl ccache cl" | ||
# export USE_PCH= if you experience trouble with precompiled headers | # export USE_PCH= if you experience trouble with precompiled headers | ||
− | == | + | == Dependencies == |
'''nodep''' | '''nodep''' | ||
− | If you set the environment variable < | + | If you set the environment variable <tt>nodep</tt> to <tt>TRUE</tt>, then dependendy information files are not created, and the build finishes faster. |
− | {{ | + | {{Warn|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.}} |
'''NO_HIDS''' | '''NO_HIDS''' | ||
− | Similar to the < | + | Similar to the <tt>nodep</tt> 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. |
− | == | + | == Parallel builds == |
− | If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism | + | If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile (directory) level, the other one on the global level. The two levels of parallelism result from the two-step build procedure in the OOo build environment. The build script runs through all the directories it reads from the build.lst files in all modules and calls dmake for every directory. |
'''parallelism on the global level''' | '''parallelism on the global level''' | ||
− | For parallelism on the global level, you have to run build from < | + | For parallelism on the global level, you have to run build from <tt>$SRC_ROOT>/instsetoo_native</tt> with the <tt>-P<number></tt> switch, for example: |
<pre> | <pre> | ||
build -P2 | build -P2 | ||
Line 413: | Line 442: | ||
Experience tells that using the doubled number of cores in your machine is a good choice, using more threads does not make a big difference, except if the combined option is chosen. So even on single core machines using two threads will speed up the build considerably. | Experience tells that using the doubled number of cores in your machine is a good choice, using more threads does not make a big difference, except if the combined option is chosen. So even on single core machines using two threads will speed up the build considerably. | ||
− | == | + | == Create prebuilt mozilla == |
− | For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed). | + | For the mozilla-components, you have the choice to either build from mozilla sources, to use precompiled packages 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). | 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: | To do so: | ||
− | * build the < | + | * build the <tt>moz</tt> module from the mozilla sources |
− | * use < | + | * use <tt>--enable-build-mozilla</tt> when running configure and put the mozilla-source tarball to <tt>moz/download</tt> |
− | * in < | + | * in <tt>moz</tt> run <tt>dmake zip</tt> to create the zip files |
− | * you'll find the zips in < | + | * you'll find the zips in <tt>{platform}.pro/zipped</tt> |
Copy them to a location of your liking. | Copy them to a location of your liking. | ||
− | Now instead of using < | + | Now, instead of using <tt>--enable-build-mozilla</tt>, use <tt>--disable-build-mozilla</tt>, copy the zips you created or downloaded to <tt>moz/zipped</tt>, 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). | This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla). | ||
− | = See | + | = See also = |
− | {{ | + | {{Note|For more information on building OOo on Windows see: |
* [[Building on Windows (older releases)]] | * [[Building on Windows (older releases)]] | ||
* [[CPAN_install| Perl modules installation with CPAN]] | * [[CPAN_install| Perl modules installation with CPAN]] | ||
Line 434: | Line 464: | ||
* [http://website.openoffice.org/support/en/howtos/1.html#1 Documentation on website.openoffice.org]}} | * [http://website.openoffice.org/support/en/howtos/1.html#1 Documentation on website.openoffice.org]}} | ||
− | + | ---- | |
− | + | <references/> | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
{{PDL1}} | {{PDL1}} |
Latest revision as of 08:32, 16 July 2018
Contents
Overview
This document explains how to build the OpenOffice.org source code on Windows systems with MinGW compiler and linker. |
What is MinGW?
MinGW stands for Minimalist’s GNU for Windows. It is a set of firee, open source software including compiler, linker,shell environment and other useful tools for developing software. MinGW is intended to support developing software to work on Microsoft 32-bit Windows with minimal support of external libraries. The MinGW community is distributing the g++ compiler from gcc (GNU compiler collection) and GNU ld linker for Windows 32-bit executables in GNU binutils, which is a set of tools to manipulate binary object and executable files.
The reason why MinGW build is being maintained
Please note the official releases of OpenOffice.org for Windows are built using tools from Microsoft. The build with MinGW compiler and linker is being maintained for checking the code portability and keeping the alternative to Microsoft tools. Microsoft compiler does not complain at some codes violating C++ standard and although Microsoft is supplying Visual Studio Express edition free of charge for the time being, they may stop to do so in the future. And it may make sense to keep OOo to be buildable with open source tools.
Cygwin
For building OpenOffice.org, Cygwin is needed, a Windows program that emulates a complete Unix command-line environment. To use this document, you need to be familiar with a command line, but you need not to be a UNIX shell wizard.
If you have never used a Unix shell, you might want to take a look at the shell introduction at TLDP. |
You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases. |
Cygwin compiler vs. MinGW compiler
Cygwin also includes C++ compiler and linker in its distribution, as well as headers and libraries of MinGW. Specifying -mno-cygwin command line switch, the tools can generate the same object code to MinGW compiler. However, as the tools use Cygwin system call to invoke sub programs, the process to build OpenOffice.org with Cygwin’s compiler and linker is a bit slower and more unstable than that with “pure” MinGW tools on Cygwin shell.
Versions and problems in compiler and linker
The version of the official release of gcc from MinGW is gcc-3.4.5 for version 3 series and gcc-4.4.0 for version 4 series. 4.4.0 is the first official release of version 4 series and older versions in version 4 series were all experimental. Cygwin includes gcc-3.4.4 and experimental 4.3.2. Compilers of version 3 series have several problems to build OOo and needs patches. You can get the patched binaries of core C compiler and C++ compiler at ooopackages.good-day.net. Available version is only 3.4.4. The source patch is also available there. You can get the patched compilers equivalent to them in Cygwin distribution. You have to get core C compiler, C++ compiler and the MinGW libraries for both C and C++ at ooopackages.good-day.net. Please note that you have to run the postinstall command in /etc/postinstall directory after extracting the distribution of both of the MinGW libraries for C on Cygwin and that for C++ under root directory in Cygwin command prompt. Compilers of version 4 series have no serious problem to build OOo but the standard C++ library distribution included in the official release of gcc-4.4.0 is only partial and needs to be rebuilt using a Cygwin shell script. Gcc version 4 emits better code and useful warning messages. However, you should concern licence agreements of dlls. MinGW gcc compiler has restriction to use dynamic linking of the two library libgcc and libstdc++ for proper exception handling and the dlls will be included in the installation set you will build. In the meantime the licence agreements of these dlls have a rather strict term to follow if you redistribute them. The version of the official release of binutils from both MinGW and Cygwin is 2.19.18 and ld linker has problems to build OOo. The patched binaries and sources are available at ooopackages.good-day.net.
w32api and MinGW runtime library
The set of libraries and headers to let code to use Windows API is distributed as w32api. The version 3.13 is required for building OOo. Some new APIs and constant definitions that are not officially published from Microsoft are not included and you have to use files in Microsoft SDK with smalll patches. MinGW runtime library of version 3.16 is required as well to enable multithreading and fix some C functions. MinGW tools are intended to use Microsoft C runtime library that is always installed in Windows system but some bugs are fixed in MinGW runtime library.
Requirements
Hardware requirements
- 1 or more reasonable fast CPUs (x-way CPU recommended)
- 1 GB RAM (2 GB recommended)
- 10 GB free disk space (20 GB when debugging)
Software requirements
- Windows XP/Vista
The following table is placed here, so you can come back to it easily, when you want to use a link. The items are explained below. Here's the list of files to download (with links) and the locations in the source tree where you must put them:
Adding required files to the build tree
Some of the files can be found in a suitable OOo installation set also, so you can save the download by “stealing” it from your OOo installation. |
Installation and preparation of build tools
Setting up cygwin
Go to http://www.cygwin.com/ and download and install the current version.
Required additional packages
Cygwin consists of some basic and a lot of optional packages. As building OOo needs some of these optional packages you have to select them in the installer. Here's a complete list of the needed packages:
- Category Archive:
- cabextract
- unzip
- zip
- Category Devel :
- autoconf
- bison
- flex
- gcc-g++
- gperf
- make
- openssl-devel (only needed for perl modules for CWS tooling, see below)
- pkgconfig
- cvs (for 2.x code line and 3.0 code line)
- subversion (for 3.x code line, minimum version 1.5.5)
- Category Libs
- openssl
- Category Net
- openssh
- ncftp
- rsync
- Category Perl
- perl
- Category Shells
- rxvt
- Category Utils
- file
- patch
- gnupg
- Category Web
- lynx
- wget
Unfortunately the list of packages mentioned at http://website.openoffice.org/support/en/howtos/1.html#1 is incomplete, some more are listed at http://tools.openoffice.org/dev_docs/build_windows_tcsh.html#BuildRequirements . |
The installer will automatically check and download some more packages needed by thosed listed here. The whole process takes roughly 20 minutes. |
Breaking links to executables
Within the Cygwin Toolkit, some executables might be symlinks: awk.exe and gunzip.exe, tar.exe (in older releases only). This can lead to a break of the build later, and the symlinks should be replaced by copies of the command they link to.
To check this, execute:
ls -l /bin/awk.exe
whether e.g. awk.exe is a symlink. In version 1.5.24-2 awk.exe is a link to gawk.exe. The shell will show this by putting out “awk.exe -> gawk.exe”. In this case gawk.exe must be copied to awk.exe by executing:
cd /bin rm awk.exe cp gawk.exe awk.exe
In case you overlook something here or you have a newer Cygwin version with additional symlinks not mentioned here, it's not a problem. You will get a helpful error message about an existing link in the configuration step (configure) later. The message will tell you which link you have to remove, and you can do it following the advice given above for the awk.exe/gawk.exe pair.
Installing additional perl modules in cygwin
As explained some perl modules must be installed with CPAN. The necessary command in the cygwin shell is
perl -MCPAN -e shell
If this command is executed, the first time CPAN will ask for configuration. Choose autoconfiguration.
At the end, the CPAN shell appeared and is ready to accept commands for installations. Each module is installed by typing install $MODULENAME. The modules that must be installed are:
- Archive::Zip
- XML::Parser (though it seems that this is already installed; doesn't hurt to do it)
- URI
- LWP::UserAgent
- Crypt::SSLeay
- SOAP::Lite
CPAN will detect if a selected module depends on other modules and it will offer to download them also. As explained please just confirm this.
The last three modules are only needed if you want to use the cws tooling. These tools are necessary if you want to create and maintain your own Child Workspaces or if you want to build one of them. I recommend to install them anyway as sooner or later you want to work on a child workspace. |
Installing compiler and binutils
Installing “pure” MinGW gcc version 3 series compiler and binutils
To install “pure” MinGW gcc version 3 series compiler and binutils, you have to create a unique directory first, say c:/mingw. All you have to do is to extract all tarballs here.
tar -C c:/mingw -xvzpf xxx.tar.gz
Installing “pure” MinGW gcc version 4 series compiler and binutils
To install “pure” MinGW gcc version 4 series compiler and binutils, you have to choose a unique directory name, say c:/mingw, put everything you downloaded in one working directory and invoke the following command in the directory.
./gcc-core-g++-4.4.0-install.sh c:/mingw
Extend the path to get the right compiler:
export PATH=/cygdrive/c/mingw/bin:$PATH
Installing Cygwin gcc version 3 series compiler and binutils
You have to extract all tarballs in root directory.
tar -C / -xvjpf xxx.tar.gz
The tarballs for gcc-mingw-gcc and gcc-mingw-g++ include postinstall scripts. You have to run them to complete installation.
/etc/postinstall/gcc-mingw-core.sh /etc/postinstall/gcc-mingw-g++.sh
Full builds
configure
Finally the configure tool is used to create the environment. It checks that all software, hardware, and system requirements for the build are satisfied, and creates configuration files called winmingw.set (for tcsh) and winmingw.set.sh (for bash) that are used to set all necessary build environment variables. Before running configure, make sure that all needed programs are in the system path or start configure with the appropriate command line switches. If configure detects a problem it will stop and give you a useful hint how to fix it.
You will find the configure script in $SRC_ROOT. The resulting configuration files are created there too.
Sample configure calls
./configure \ --with-mingwin=yes \ --disable-directx \ --disable-activex \ --disable-atl \ --disable-build-mozilla \ --with-frame-home="/cygdrive/c/PROGRA~1/MI2578~1/Windows/v6.1" \ --with-psdk-home="/cygdrive/c/PROGRA~1/MI2578~1/Windows/v6.1" \ --with-midl-path="/cygdrive/c/PROGRA~1/MI2578~1/Windows/v6.1/Bin" \ --with-jdk-home="/cygdrive/c/PROGRA~1/j2sdk1.4.2_11" \ --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" \ --with-ant-home=/ant \ --with-mozilla-build=/cygdrive/c/mozilla-build/moztools \ --with-nsis-path=/cygdrive/c/PROGRA~1/NSIS
./configure \ --with-mingwin=yes \ --disable-activex \ --disable-atl \ --disable-build-mozilla \ --with-frame-home="/cygdrive/c/PROGRA~1/MI2578~1/Windows/v6.1" \ --with-psdk-home="/cygdrive/c/PROGRA~1/MI2578~1/Windows/v6.1" \ --with-midl-path="/cygdrive/c/PROGRA~1/MI2578~1/Windows/v6.1/Bin" \ --with-jdk-home="/cygdrive/c/PROGRA~1/j2sdk1.4.2_11" \ --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" \ --with-ant-home=/ant \ --with-mozilla-build=/cygdrive/c/mozilla-build/moztools \ --with-nsis-path=/cygdrive/c/PROGRA~1/NSIS \ --enable-crashdump \ --enable-symbols=SMALL \ --enable-vba \ --enable-minimizer \ --enable-presenter-console \ --enable-pdfimport \ --enable-wiki-publisher \ --enable-report-builder \ --enable-cairo
configure settings tips
Paths to dependencies might be different for your installation. The paths containing "msvc" and "msdk" should be self-explanatory. |
There are a number of options that you can use with the configure script. To display these options, type the following command:
./configure --help |
OOo uses some Mozilla components. Disabling the Mozilla components completely with --disable-mozilla currently might not work due to a bug in the module dependencies. |
csc.exe comes from the c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 directory, you might need --with-csc-path. |
If you fail to getting together a working installation of Cygwin, one possibility is to use a known-to-work combination of Cygwin packages, i.e. a direct copy of some other user's Cygwin tree. User:TorLillqvist has such a tree (from late 2006) zipped up at http://download.go-oo.org/tstnvl/tml/tml-cygwin.zip . Don't hesitate to ask for advice if necessary. |
bootstrap
After running configure you must create the dmake make utility that is needed for the build of OpenOffice.org. This done from the SRC_ROOT directory by calling
./bootstrap
Setting the environment
When the configure script has been run successfully a file winmingw.Set.sh was created[6]. Do this:
source winmingw.Set.sh
to set up the environment for the build.
Starting the build
Build the software by typing the following in $SRC_ROOT [7]:
dmake
The building procedure will take at least an hour (on a 3 GHz Quad-Core with 8GB RAM).
There are some special things in the way how OOo builds its modules. Every module has an “output” folder (with some subfolders for the different kinds of generated output) that is created the first time a build is done in the module. The name of this folder is “wntgcci.pro” (for the meaning of the "pro" extension see below). After a successful build of a module some of the generated files are copied to the output folder of the “solver” module by executing a tool called “deliver” (this is automatically called by build --all for each of the modules). Other modules will take these “delivered” files (header files, libraries etc.) to resolve their dependencies. The content of the solver module will also be used to pack the installation sets in the final step.
Using some not quite latest cygwin releases (1.5.18/1.5.19) can lead to tcsh freezing in places - the build will appear to hang. You can fix this by running ls /proc/$nnn/fd where $nnn is the number of the process. Or just run
ls /proc/*/fd to "unhang" the process. See Issue 51560 for more info... |
Partial builds
There are two ways to do partial builds:
- compatible
- incompatible
Only do compatible partial builds if you know exactly what you are doing.
For more information, see Compatible Builds. |
Rebuilding from a module (incompatible build)
If you decide to change a module in an incompatible way, you will need to rebuild all modules depending on it (directly or indirectly):
cd $SRC_ROOT/instsetoo_native build --from $INCOMPATIPLEMODULE --prepare build --from $INCOMPATIBLEMODULE
Rebuilding a module (compatible build)
To rebuild a module you can delete all output directories with, rebuild and redeliver into the solver with:
cd $MODULE build --from $MODULE --prepare build && deliver
A simple build in $SRC_ROOT/instsetoo_native will recreate the installation sets, provided all other modules have already been build. [8]
Building a module with debug information
To rebuild a module with debug information and additional assertions and checks, run:
cd $MODULE build --from $MODULE --prepare # removes old output trees and solver build debug=true --from $MODULE
Drop the newly created binaries into an existing installation. Building an installation set with them will not help, as binaries are stripped on packing by default.
For details, see Windows Debugging. |
Finding the installation sets
After a successful build you will find the OOo installation set in
instsetoo_native/wntmscixx.pro/OpenOffice/msi/Install/en-US
“instsetoo_native” is the module that packs the installation set.
If you already have a version of OOo installed you can install your freshly built version in parallel by installing it with setup /a that just unpacks all files without any system registration. |
Tips and tricks
ccache
For Windows: download from 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
Dependencies
nodep
If you set the environment variable nodep to TRUE, then dependendy information files are not created, and 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. |
NO_HIDS
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.
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 (directory) level, the other one on the global level. The two levels of parallelism result from the two-step build procedure in the OOo build environment. The build script runs through all the directories it reads from the build.lst files in all modules and calls dmake for every directory.
parallelism on the global level
For parallelism on the global level, you have to run build from $SRC_ROOT>/instsetoo_native with the -P<number> switch, for example:
build -P2
This takes build how many dmake processes it is allowd to start in parallel.
parallelism on the directory level
export MAXPROCESS=<numer or processes>
This tells dmake how many targets it is allowed to build in parallel. When you don't use build.pl but build a single directory (single makefile), you can achieve the same with
dmake -P2
combining both levels
If you want to have parallelism on both levels, you can call
build -P2 -- -P2
"--" is a special build.pl parameter that passes every further parameters to the dmake processes it starts.
Recommendation
Experience tells that using the doubled number of cores in your machine is a good choice, using more threads does not make a big difference, except if the combined option is chosen. So even on single core machines using two threads will speed up the build considerably.
Create prebuilt mozilla
For the mozilla-components, you have the choice to either build from mozilla sources, to use precompiled packages 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 moz module from the mozilla sources
- use --enable-build-mozilla when running configure and put the mozilla-source tarball to moz/download
- in moz run dmake zip to create the zip files
- you'll find the zips in {platform}.pro/zipped
Copy them to a location of your liking. Now, instead of using --enable-build-mozilla, use --disable-build-mozilla, copy the zips you created or downloaded to moz/zipped, 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).
See also
- ↑
This also supported on Vista. This is either a DVD image or a net installer. You can either mount the DVD with a suitable tool, burn it do a DVD or use tools like winrar that can extract files from ISO files directly. You don't need to install samples or documentation (saves a lot of disk space). It will also install the .NET Framework 3.5 SDK. It might be best to install the Windows SDK into the default directory, and if not that into one without capital letters in the path. I used D:\Dev\Win_SDK\ and received some linking errors in the Python module (see Issue 88568 ).
- ↑
- ↑
- ↑
If NSIS is available, a self contained Windows installer is created in addition to the MSI installer files. It used to be that newer version of NSIS broke the build (see Issue 85657 ), but it seems that it now works for NSIS up to 2.3.7. - ↑
If you don't want to download it you can disable DirectX support in the configuration step (--disable-directx). Current (as of 2008/01) versions of the DirectX9 SDK and Windows Platform SDK do not fit to each other. To be able to build with DirextX enabled, you need to patch one file in the Platform SDK. See http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID2743771 for details. - ↑
- ↑
- ↑
Content on this page is licensed under the Public Documentation License (PDL). |