Installing and Building the OpenOffice Prototype

Edward Peterlin, Dan Williams



Introduction has recently reached a crucial milestone, the beta build for Darwin. The project has now entered the next major phase, migration to a Quartz implementation and Aquafication. This undertaking will probably take a significant amount of time and a large expenditure of resources. As such, it makes sense to take some time to explore some of the potential paths for execution so a year from now we don't find we made the wrong choice of strategies.

OpenOffice is an exploration of the strategy of executing an OS X native port on top of the existing Cocoa+QuickDraw VCL implementation. It is a complete hack job, is unstable, rails the processor, leaks memory, has drawing glithces, is mostly unmaintainable code, and does not integrate well with the potentially changing VCL of in future versions. It does, however, illustrate that the existing infrastructure can be pushed to create results that are fairly desirable.

Through this prototyping process we discovered several bugs and issues that make this approach undesirable:


Getting OpenOffice and External Sources

Once you have the requirements for building OpenOffice met by performing a small contract job or assuming a decent amount of credit card debt for a new hard drive, it's time to get the OpenOffice sources and other external sources. If you've built OpenOffice from previous sources and have applied other patches, you will need to start either with a source tarball, or with the CVS sources.

To download the CVS distribution:

  1. Open a new Terminal (/Applications/Utilities/Terminal)
  2. mkdir /neooffice
  3. cd /neooffice
  4. setenv CVSROOT
  5. cvs login
  6. Enter the password anoncvs
  7. cvs co OpenOffice
  8. go get some coffee, or a beer, since it'll take a while to get it all

After you get the CVS distribution you will need to take some steps to set up a build properly. OpenOffice is derived from OO638C_MacOSX and requires gcc2 to build. The first step is to therefore configure your build box to use gcc2:

  1. sudo gcc_select 2

Next we build the STLPort code. This is a compiler-agnostic STL implementation used with the OOo sources. To obtain the source:

  1. cd /neooffice
  2. tar xvf macosx_extras/STLport-4.0.tar
  3. cd STLport-4.0
  4. /neooffice/solenv/unxmacxp/bin/patch-STLport-4.0
  5. Enter /neooffice/STLport-4.0 as the directory when prompted
  6. cd /neooffice/STLport-4.0/src
  7. /usr/bin/make -f gcc-apple-macosx.mak
  8. go get some more coffee, or another beer, since it'll take a while to build

After getting stlport built you will need to get the dlcompat library for linking convienence. This is needed to properly build the patches for the Darwin port.

  1. Download the dlcompat package from the project.
  2. Uncompress it and double-click the .pkg file to install the library.

Important Note: If you've installed dlcompat from a different source location, you must be sure that it's properly linked to /usr/local/lib or else the OS X build will fail.

Building OpenOffice

Now that we've got it all patched up, it's time to execute the build!

  1. Open up a new Terminal.
  2. cd /neooffice/config_office
  3. ./configure --without-x --with-stlport4-home=/neooffice/stlport-4.0
  4. Hit Enter/Return at the "Please enter Java home directory" prompt.
  5. Enter "n" and hit return at the "Directory does not exist. Do you want to create it?" prompt.
  6. cd /neooffice
  7. source MacosxEnv.Set
  8. ./bootstrap
  9. source MacosxEnv.Set (this is to rescan the PATH to locate zipdep and other executables built during the bootstrap phase)
  10. dmake
  11. Begin consuming those cases of beer. You'll be waiting about a day.

Assembling the Setup Executable

After all of OpenOffice is built, the next step is to construct the appropriate directory so we can run setup and install the binaries we've just built. From what I know, it's not possible to run them straight out of the build directory.

  1. Open up a Terminal if you closed the other one in the past couple of days.
  2. mkdir /neooffice-setup
  3. cp /neooffice/instsetoo/* /neooffice-setup/
  4. cp /neooffice/instsetoo/ /neooffice-setup/
  5. cp /neooffice/solver/638/ /neooffice-setup/
  6. cd /neooffice-setup
  7. unzip f0\*
  8. cp -f /neooffice/setup2/ /neooffice-setup/setup.bin
  9. ln -s libcppu.dylib.3.0.0 libcppu.dylib.3
  10. ln -s libsal.dylib.3.0.0 libsal.dylib.3
  11. ln -s libstore.dylib.3.0.0 libstore.dylib.3
  12. ln -s libreg.dylib.3.0.0 libreg.dylib.3

Installing OpenOffice Binaries

Now setup has all the necessary libraries and files it needs to run. The setup process will exhibit several failures, but does properly register the recognized components if it's run correctly.

  1. Open a new Terminal. Do not re-use an existing terminal that has been previously used to build OpenOffice.
  2. mkdir /neooffice-install (this is where the final executables will live)
  3. cd /neooffice-setup/
  4. setenv DYLD_LIBRARY_PATH /neooffice-install/program:/neooffice-install/program/filter
  5. sh setup
  6. When prompted for intallation directory, specify /neooffice-install as the target directory. When you're running OpenOffice binaries from the terminal it isn't possible to use the keyboard. Click on the "Browse..." button to get a file dialog. Navigate to the neooffice-install folder in the dialog and click "OK".
  7. When prompted to "Please insert the disk...", click "OK" each time
  8. There will be errors that pop up for libraries and files containing the following: dbp, spa, psp, README, LICENSE. Hit the "Ignore" button in the error prompts to continue with the installation regardless.
  9. If you get dozens of "libfoo638mxp.dylib couldn't be registered", other than dbp, spa, and psp, then your DYLD_LIBRARY_PATH didn't match the installation directory. Delete ooo-install and run setup again

Once setup has exited, we need to move some files manually. Setup hasn't been fixed to work without a hitch on OS X:

  1. cd /neooffice-install/program/
  2. cp /neooffice-setup/libstaticmxp.dylib .
  3. cp -f /neooffice/desktop/ soffice.bin
  4. cp /neooffice/solver/638/ resource/iso63801.res

What More Needs to be Done?

This patch is just a first step towards getting a fully functional build. There are a number of things which still need to be addressed before we can claim absolute victory.

  1. Integration with Mainline Sources: This patch is incredibly unstable in its current incarnatin, but we should begin migrating it to OO641/OOO_STABLE_1 sources. This patch contains several places where code may need to be ifdefed MACOSX out or commented out in the build files. Currently the patches may break other ports. If someone is working on two different ports, this may be the ideal project to start off with after the first build is done :)
  2. Integration and Evolution: We need to get this patch in a state safe for other ports, move to OO641 in preparation for OO1_STABLE, finish up all of the missing parts, etc. etc. etc. In other words, this patch represents the completion of the OO638C build step in our project roadmap and it's time to take up the ball and start heading for the endzone.

Building Test Programs

OpenOffice contains a number of test programs that can be used to exercise various parts of OpenOffice. These test programs are very useful for trying to find problems in the source code that may cause errors while running OpenOffice. The vcl test programs are incredibly useful for debugging problems when building Aqua graphics.

Once you have built the modules in the Abstraction and Infrastructure Layers, you are now ready to build the test programs for these layers. To build the test programs, execute the following commands:

> cd $SRC_ROOT/svtools/workben ; dmake ; deliver
> cd $SRC_ROOT/stoc/test/testsmgr_cpnt ; dmake ; deliver
> cd $SRC_ROOT/stoc/test ; dmake ; deliver
> cd $SRC_ROOT/bridges/test/java_uno ; dmake ; deliver
The commands listed above will build the following test programs. As these test programs are meant to provide a means for developers to debug the modules that are in the Abstraction and Infrastructure Layers, developers are highly encouraged to run these test programs on a platform such as Windows, Linux, or Solaris to determine what additional porting development effort is needed:

Building Individual Projects

OpenOffice is organized in several projects. For example, the Word Processing Project. These in turn consist of several modules, organised in separate directories. The source contains approximately 90 modules.

You can build any project or module individually. Building modules individually should not be misunderstood as reducing OpenOffice to a special application, say, for instance, the spreadsheet application. The program will always consist in the entire office suite: text processor, spreadsheet, drawing application etc. Building individual modules comes in handy if you want to develop on a certain module or port a module that has not yet been ported for this plaform. Most modules will depend on other modules to be already built. In other words, all modules must build in a particular order. Accordingly, you must build all of the modules in the Abstraction and Infrastructure Layers before you trying building any projects or modules individually.

For more information on modules and on the sequence that they build in, and on the dependencies, see

To build a project, you build each of its modules individually in their directory with the build tool.

> cd $SRC_ROOT/(module-name)
> $SRC_ROOT/(module-name)> build
> $SRC_ROOT/(module-name)> deliver
Files called makefile.rc in each directory with further subdirectories iterate through all directories of the module and executes dmake in each of them (just like the top-level makefile.rc does when building the entire office suite). The last or second to last directory is usually module-name/util which is responsible for linking one or more shared libraries.

Building a Project with Debug Information

To rebuild a complete project with debug information, remove all object files by removing the directory. Then run dmake with the debug option set to true:

> cd $SRC_ROOT/(module-name)
> $SRC_ROOT/(module-name)> rm -Rf
> $SRC_ROOT/(module-name)> build debug=true
> $SRC_ROOT/(module-name)> deliver

Re-running Setup to Reinstall OpenOffice

After you've built a module with debug symbols, chances are you'll want to reinstall OpenOffice in order to run OpenOffice with debugging information. The first thing you'll need to do is remove setup, the install directory, and some config files. If you installed to the paths suggested above, this can be accomplished with the following set of commands:

  1. rm -rf /ooo-install
  2. rm -rf /ooo-setup
  3. rm ~/.sversionrc

After getting rid of the setup directory, install directory, and the .sversionrc file we need to recreate the setup executable. First we need to reconstruct the zip files in instsetoo:

  1. cd /openoffice
  2. source MacosxEnv.Set
  3. cd instsetoo
  4. build

Now you can resume the instructions in Assembling the Setup Executable and complete with the installation. You can then get debug symbols by gdb sh and then issuing r /path/to/soffice

Deleting a Build Directory

When you're deleting a directory containing a checkout of the OpenOffice sources, you should rm -rf it from a terminal. If you are trying to delete your checkout using the Finder, you'll run into a fun little feature of the OS X Finder that doesn't allow you to delete folders named desktop. OpenOffice has a folder with this name in it, and this folder will need to be deleted from the terminal.

Moving or Renaming a Build Directory

The build process for OpenOffice utilizes hardcoded paths to STLPort and other components of the source tree. If you rename your OpenOffice build directory or if you move it to a new location, you should delete all binaries and start from scratch by runnint config_office/configure again. To erase all your object files:

  1. cd $SRCROOT
  2. find . -name -print0 | xargs -n 1 -0 rm -rf

If you do not perform this step, you will most likely be unable to build or link out of your build directory any longer.