Skip to content

start:

Technical Overview of Porting

This section lists the status of ports, and also discusses issues to consider when creating a new port.

Port status

Porting Status for Various Operating Systems
Ports in Development People working on it Status
Mac OS X Eric Bachard, Tino Rachui, Stephan Schäfer, Florian Heckl current stable: OpenOffice.org 2.0.x (X11) for Intel and PowerPC
680 Milestone builds available
Linux PPC Eric Bachard and Rene Engelhard Complete
Linux Sparc Jim Watson Complete
Linux x86_64 Jan Holesovsky Complete
Linux PPC64 Caolan McNamara Complete
Linux MIPS (el) lemote and Sunil Amitkumar Janki Complete
Linux MIPS (eb) Caolan McNamara Complete
Linux ARM (oabi) Peter Naulls, Scott Hutinger and Tak-Shing Chan. Complete
Linux ARM (eabi) Caolan McNamara Complete
Linux IA64 Caolan McNamara Complete
Linux S/390 Gerhard Tonn Complete
FreeBSD Martin Blapp and Nakata Maho Complete (QA needed)
IRIX Nick Blievers In development
NetBSD/i386 Michael Rauch In development
NetBSD/sparc Michael Rauch In development (Stalled)
Tru64 Yi Wang In development
VMS Ton van der Zwet and Martin Borgman In development
OS/2 Jochen Schaefer and Brian Smith In development (stalled ?)
HP/UX Peter Van Nieuwenhoven In development - help wanted in bridges code
AIX Ken Foskey In development but slow
BeOS ?????? Unknown

Porting Issues

You need to consider the issues in the following sections before you port to a new environment.

Environment Setup

Adoption of the configure scripts required.

Compiler

One of the main issues for porting the office suite is to have a working C++ compiler. The following C++ features cause the most difficulties for compilers:

  • Use of the Standard Template Library (STL). The office suite uses STLport 4.x, which is an SGI STL adaptation. Conflicts can arise with native includes. By default for new linux ports configure will default to using the compilers STL and not STLport 4.x, this is the recommended approach where possible.
  • Deliberate use of templates as a whole.
  • Namespaces.
  • Exceptions, using exceptions over shared library boundaries (run the ehtest suite in STLport for verification)
  • Order of initialization and destruction of global objects, especially since there are a lot of different but dependent shared libraries involved.
  • Usage of GCC on most platform recommended (2.95, 3.0 and 3.1 currently supported)

Platform-Dependent Implementation

The most difficult part about platform-dependent implementation is language binding, since it requires some knowledge of the CPU architecture and how the compiler constructs vtables and so on. This is a time-consuming activity. For existing ports, this is implemented in the module bridges.

Loading Shared Libraries

Another area where some development might be necessary is the loading of shared libraries. The source code assumes the availability of dlopen() and associated files. For example HPUX 10.x uses something like shl_load() and names shared libraries differently, however the necessary changes should be minor.