Most tarballs include the following files in the top-level directory:

These files contain useful information that may help you get the application running on Mac OS X.

One of the first difficulties you may encounter when running a configure script is that the script aborts with an error message stating that the host system cannot be determined.

Strictly speaking, the host type refers to the system on which software will run, and the build type refers to the system on which the software is being built. It is possible to build software on one system to run on another system, but to do so requires a cross-compiler. We will not concern ourselves with cross-compiler issues. Thus, for our discussion, both the host type and the build (and target) types are the same: powerpc-apple-darwin VERSION, where the VERSION denotes the particular version of Darwin. In fact, a configure script detects Mac OS X by the host/build type named Darwin, since Darwin is the actual operating system underlying Mac OS X. This can be verified by issuing the uname -v command, which tells you that you’re running a Darwin kernel, the kernel version, and when it was last built.

Many configure scripts are designed to determine the host system, since the resulting makefiles differ depending on the type of system for which the software is built. The configure script is designed to be used with two files related to the host type, usually residing in the same directory as the configure script. These files are config.guess, which is used to help guess the host type; and config.sub, which is used to validate the host type and to put it into a canonical form (such as CPUTYPE-MANUFACTURER-OS, as in powerpc-apple-darwin8.0.0).

Although Mac OS X and Darwin have been around for a while now, you may still run across source code distributions that contain older config.* files that don’t work with Mac OS X. You can find out if these files support Darwin by running the ./configure script. If the script complains about an unknown host type, you know that you have a set of config.* files that don’t support Darwin.

In that case, you can replace the config.guess and config.sub files with the Apple-supplied, like-named versions residing in /usr/share/automake-1.6. These replacement files originate from the FSF and include the code necessary to configure a source tree for Mac OS X . To copy these files into the source directory, which contains the configure script, simply issue the following commands from within the sources directory:

    cp /usr/share/automake-1.6/config.sub .
    cp /usr/share/automake-1.6/config.guess .

When using the cc command, which supports more than one language, the language is determined by either the filename suffix or by explicitly specifying the language using the -x option. Table 11-2 lists some of the more commonly used filename suffixes and -x arguments supported by Apple’s version of GCC.

Although the HFS+ filesystem is case-insensitive, the cc compile driver recognizes the uppercase C in a source file. For example, cc foo.C invokes cc’s C++ compiler because the file extension is an uppercase C, which denotes a C++ source file. (To cc, it’s just a command-line argument.) So, even though HFS+ will find the same file whether you type cc foo.c or cc foo.C, what you enter on the command line makes all the difference in the world, particularly to cc.

When you invoke cc without options, it initiates a sequence of four basic operations, or stages: preprocessing , compilation, assembly, and linking. In a multifile program, the first three stages are performed on each individual source code file, creating an object code file for each source code file. The final linking stage combines all the object codes that were created by the first three stages, along with user-specified object code that may have been compiled earlier into a single executable image file.

In Mac OS X, a framework is a type of bundle that is named with a framework extension. Before discussing the framework type of bundle, let’s first briefly describe the notion of a bundle. A bundle is an important software packaging model in Mac OS X consisting of a directory that stores resources related to a given software package, or resources used by many software packages. Bundles, for example, can contain image files, headers, shared libraries, and executables. In addition to frameworks , there are at least two other types of bundles used in Mac OS X; applications (named with the .app extension), and loadable bundles including plug-ins (which are usually named with the .bundle extension).

The application and plug-in type bundles are built and organized so that the top level directory is named Contents. That is, the directory Contents/ contains the entire bundle, including any file needed by the bundle. Take for example, Safari. If you Control-click on the Safari application in the Finder and select Show Package Contents, the Contents/ directory will be revealed in the Finder. To see what’s in the Contents/ directory, quickly hit ⌘-3 to switch the Finder to Column View, and then hit the C key on your keyboard (this highlights the Contents folder). You will see the typical contents of an application bundle, including:

Applications can also contain application-specific frameworks , that is, frameworks that are not used by any other application or plug-in.

    -F directoryname

    #include <framework/filename.h>

    cc -F dir1 -F dir2 -no-cpp-precomp myprog.c

#include <Appkit/AppKit.h>

int main(int argc, const char *argv[])
{
  NSLog(@"Hello, World
");
  return 0;
}

    cc -framework AppKit -o hello hello.m

You can see the gcc manpage for an extensive list of compiler flags. In particular, the gcc manpage describes many PowerPC-specific flags, as well as Darwin-specific flags. Table 11-3 describes a few common Mac OS X GCC compiler flags that are specific to Mac OS X. These flags should be used when porting Unix-based software to Mac OS X. We’ve also included a few flags that enable various Tree-SSA-based optimizations. These are the flags that begin with -ftree.

The Velocity Engine, Apple’s name for Motorola 128-bit AltiVec vector processor that allows up to 16 operations in a single clock cycle, is supported on both G4 and G5 processors by the Mac OS X GCC implementation. The Velocity Engine, which executes operations currently with existing integer and floating-point units, can result in significant performance gains, especially for highly parallel operations. The compiler flag -maltivec can be specified to compile code engineered to use the AltiVec instruction set. Inclusion of this command-line option to cc defines the preprocessor symbol _ _VEC_ _. (See Table 11-3 for more AltiVec-related compiler flags.)

On a 32-bit system, such as Mac OS X running on the G3 or G4, C pointers are 32 bits (4 bytes). On a 64-bit system, such as Mac OS X running on the G5, they are 64 bits (8 bytes). As long as your code does not rely on any assumptions about pointer size, it should be 64-bit clean. For example, on a 32-bit system, the following program prints “4”, and on a 64-bit system, it prints “8”:

    #include <stdio.h>
    int main( )
    {
      printf("%d
", sizeof(void *));
      return 0;
    }

Some 64-bit operating systems, such as Solaris 8 on Ultra hardware (sun4u) and Mac OS X Tiger on G5 hardware, have a 64-bit kernel space, but support both 32- and 64-bit mode applications, depending on how they are compiled. On a G5 system, the pointer size is 64-bits. Other data types are mapped onto the 64-bit data type. For example, single precision floats, which are 32-bit, are converted to double precision floats when they are loaded into registers. In the registers, single precision instructions operate on these single precision floats stored as doubles performing the required operations on the data. The results, however, are rounded to single precision 32-bit. Apple has provided several technical documents containing information and advice on optimizing code to take advantage of the 64-bit G5 architecture:

The architecture of the G5 allows for much greater performance relative to the G4. This performance potential is partly due to the fact that the G5 allows 200 instructions in core, compared to only 30 for the G4. Moreover, the G5 has 16 pipeline stages, 2 load/store units, and 2 floating points units, compared to 7 pipeline stages, 1 load/store unit, and 1 floating points unit on the G4. The L1 cacheline size is also 128 bytes on the G5, compared to 32 bytes on the G4. Additionally the processor and memory bandwidth is much greater on the G5, relative to the G4. The technical notes mentioned earlier in this section have additional information on hardware differences.

One important implication of the greater number of pipeline stages on the G5 relative to the G4 is that instruction latencies are greater on the G5. You can often gain significant improvements in performance by using performance tools to identify loops that account for a large percentage of computation time. Once identified, you can either manually unroll these loops, or use the -funroll-loops compiler flag. The compiler flag -mtune-970 can also be useful in this situation, as it schedules code more efficiently for the G5. The -fast compiler flag sets these options (among others) automatically.

To better take advantage of the longer cacheline size in L1 cache on the G5, algorithms should be designed for greater data locality, and use contiguous memory accesses when possible. For example, arrays in C store entries row-wise. To ensure contiguous memory accesses, design your code so that it accesses array elements row-by-row. The G5 has four hardware prefetchers, which (if accesses to memory are contiguous) are triggered automatically to help reduce cache misses. Performance tools, such as the CHUD suite (see Chapter 12), can help you optimize code by profiling computation and memory usage—some of them even make suggestions on how to improve performance.

While the G5 running Mac OS X Panther provided a fine computing platform, Mac OS X Tiger, which allows applications to access a 64-bit address space, opens up a new realm of computational capabilities. Since Tiger supports 64-bit arithmetic instructions on PowerPC architectures, even if your code is compiled in 32-bit mode, your code will not necessarily run more efficiently when compiled in 64-bit mode. It should be noted that, even on a G3 system, 32-bit applications have a 128-bit long-double data type, and a 64-bit long-long data type.

To compile 64-bit code using GCC, be sure to use the GCC 4.0, and specify the ppc64 architecture with -arch ppc64. The -arch ppc compiler flag together with -arch ppc64 produces a “fat” binary, that is, one that can be run on either 32-bit or 64-bit systems. When a fat binary is run on a 64-bit system, it runs as a 64-bit executable. On the other hand, when the same fat binary is run on a 32-bit system, it runs as a 32-bit executable. Specifying the -arch ppc compiler flag alone produces a 32-bit executable. Since 32-bit is the default, it is unnecessary to specify this flag alone, Additionally, the -Wconversion compiler flag may be useful when converting 32-bit code to 64-bit code. The _ _LP64_ _ and _ _ppc_ _ macros can be used to conditionally compile 64-bit code. At the time of this writing, only C and C++ can be compiled in 64-bit mode. Following is a list of things to bare in mind when engaging in 64-bit computing on Tiger.

CPU architectures are designed to treat the bytes of words in memory as being arranged in big- or little-endian order . Big-endian ordering has the most significant byte in the lowest address, while little-endian has the most significant byte at the highest byte address.

The PowerPC is bi-endian, meaning that the CPU is instructed at boot time to order memory as either big- or little-endian. In practice, bi-endian CPUs run exclusively as big- or little-endian. In general, Intel architectures are little-endian, while most, but not all, Unix/RISC machines are big-endian. Table 11-4 summarizes the endian-ness of various CPU architectures and operating systems. As shown in Table 11-4, Mac OS X is big-endian.

As far as inline assembly code is concerned—if you have any—it will have to be rewritten. Heaven help you if you have to port a whole Just-In-Time (JIT) compiler! For information on the assembler and PowerPC machine language , see the Mac OS X Assembler Guide (/Developer/ADC Reference Library/documentation/DeveloperTools/Reference/Assembler/index.html).

If you cannot find binaries for X11-based applications or prefer to build the applications yourself, many tools are available to do so. When you install the Xcode Tools, make sure you install the optional X11SDK , which contains development tools and header files for building X11-based applications. If you didn’t install X11SDK when you first installed Xcode, you can still install it from the Xcode folder on the Mac OS X Install DVD.

The process of building software usually begins with generating one or more makefile s customized to your system. For X11 applications, there are two popular methods for generating makefiles:

With imake-driven source releases, you’ll find Imakefile in the top-level source directory after you download and unpack a source tarball. After reading the README or INSTALL files, examine the Imakefile to see if you need to change anything. Then the next step is usually to issue the command:

    $ xmkmf -a

When invoked with the -a option, xmkmf reads imake-related files in /usr/X11R6/lib/X11/config and performs the following tasks recursively, beginning in the top-level directory and then in the subdirectories, if there are any:

    $ make Makefiles
    $ make includes
    $ make depend

The next steps are usually make, make test (or make check), and make instal l.

To illustrate this method of building software, consider the script in Example 11-2, which downloads and builds an X11-based game.

# Download the source tarball
curl -O ftp://ftp.x.org/contrib/games/xtic1.12.tar.gz

# Unpack the tarball
gnutar xvfz xtic1.12.tar.gz

# Change to the top-level build directory
cd xtic1.12/

# Generate the Makefile
xmkmf -a

# Build everything (some X11 apps use 'make World')
make

# Have fun!
./src/xtic

The X Window System is useful to Unix developers and users, since many Unix-based software packages depend on the X11 libraries. An interesting project that sometimes eliminates the need for X windows is the BSD-licensed AquaTerm application, developed by Per Persson (http://aquaterm.sourceforge.net). AquaTerm is a Cocoa application that can display vector graphics in an X11-like fashion. It does not replace X11, but it is useful for applications that generate plots and graphs.

The output graphics formats that AquaTerm supports are PDF and EPS. Applications communicate with AquaTerm through an adapter that acts as an intermediary between your old application’s API and AquaTerm’s API.

At the time of this writing, AquaTerm has adapters for gnuplot and PGPLOT, as well as example adapters in C, FORTRAN, and Objective-C. For example, assuming that you have installed both X11SDK and AquaTerm, you can build gnuplot (http://www.gnuplot.info) so graphics can be displayed either in X windows or in AquaTerm windows.

See AquaTerm’s web site for extensive documentation, including the latest program developments, examples, mailing lists and other helpful resources.