Language

The Free and Open Productivity Suite
Released: Apache OpenOffice 4.1.15

Interview: Patrick Luby

-Louis Suárez-Potts

1 May 2001

Getting the Mac OS X 10.0.x Port Running: Hints and Tips

There has been considerable interest in building the Mac OS X 10.0.x port of OpenOffice.org. Accordingly, over the space of a few days late in April, I asked the former manager for the Mac OS X 10.0.x port some questions that should help developers interested in building the port.

Tell us about your role in making the port....

I am a senior engineer at Sun and was the manager for the Mac OS X 10.0.x port of OpenOffice.org. I and my engineering team are now working on the Solaris and Linux ports of OpenOffice.org.

The Mac OS X 10.0.x port for OpenOffice.org code was released with work still needing to be done on it. What is the first thing that someone interested in working on the port must do?

Before anything else, anyone who wants to build the port should look at these three documents:

I think that developers should not be distracted by GUI issues. It is very tempting for developers to want to focus on GUI issues such as look and feel, graphics, and printing. However, these GUI issues are not the most critical. The most critical issues that developer should focus on are:

Currently, enough GUI support has been implemented to start up OpenOffice.org once the above three tasks are completed. Once developers can get OpenOffice.org to start up, developers can start on the remaining GUI issues.

How much time would you estimate that it takes to build the Mac OS X 10.0.x port?

It takes anywhere from 50 to 100% longer to compile Mac OS X 10.0.x for OpenOffice.org than for Linux.

Most of this increased build time is because Apple's version of the gcc compiler cannot handle static data members in template classes (see http://porting.openoffice.org/mac/macosx_issues.html). As a result, we had to implement a rather inefficient process to find and initialize all static data members within template classes. Normally, the compiler would handle this task. Developers could potentially speed up the build significantly if this compiler bug were fixed.

The remaining portion of this increased build time is due to the creation of the special packaging for shared libraries (see http://porting.openoffice.org/mac/macosx_issues.html). Currently, we run the packaging script on every shared library every time a module is delivered. Potentially, the build time could be reduced by tweaking the command in the prj/d.lst in each project so that the packaging script is run against only the shared libraries that the current module has delivered.

Can you offer any other advice that will help community members get the port moving?

Yes. First, and I think this is the most important point, if you have the ability to contribute, go to Apple's Darwin site (http://www.darwin.org) and help fix the gcc compiler's inability to handle static data members in template classes.

Second, make sure that you carefully read the documentation that I have mentioned earlier. Understanding the specifics of each technical issue will save developers a lot of unnecessary pain when working with the OpenOffice.org source code.

Third, resist the urge to focus on GUI and, instead, work on compiling the remaining modules and getting OpenOffice.org to install and start up.

Fourth, and this will help you immensely, gain an understanding of the UNO Development Kit (http://udk.openoffice.org). One of the major issues with Mac OS X 10.0.x is the duplicate symbol bug in the dynamic library loader (see http://porting.openoffice.org/mac/macosx_issues.html). By understanding how UNO components are loaded, developers will have a much easier time implementing the workaround for the Mac OS X 10.0.x bug for the many UNO components that OpenOffice.org uses.

Apache Software Foundation

Copyright & License | Privacy | Contact Us | Donate | Thanks

Apache, OpenOffice, OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. The Apache feather logo is a trademark of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.