Porting Introduction
Porting Introduction
You need to consider the issues in the following sections before you port to a new environment. Be sure that you made yourself familiar with the buildenvironemt on a working platform before you start a new port.
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 used STLport 4.x, which is an SGI STL adaptation. Conflicts can arise with native includes. Using the --without-stlport option is recommended 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 (4.1 and above are 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. The Lazy Hackers Guide To Porting gives a rough description of a sample Linux port.
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.
