UNIX 03 Conformance Release Notes

Contents:

Introduction

In an effort to increase compatibility with other UNIX operating systems, Apple has made a significant effort in OS X v.10.5 to support the Single UNIX Specification Version 3 (SUSv3). Although Apple has attempted to minimize the impact of the changes involved, some of them will affect developers who work with UNIX APIs and commands.

The OS X kernel, libraries, and utilities are drawn from a number of Open Source projects, including FreeBSD, GNU, NetBSD, and OpenBSD. Although these projects make an effort to follow industry standards, none of them have the resources to engage in a formal certification process.

By performing this work for OS X, Apple benefits both its developers (who can now rely on well-defined interfaces and behavior) and the contributing Open Source projects (whose code and documentation can be updated to include Apple's changes).

Although Apple has attempted to make the process as seamless as possible, some conformance changes are simply incompatible with commands and APIs found on earlier versions of OS X. This document provides an overview of these incompatibilities, along with information on specific changes that are likely to be problematic.

Conformance and Legacy Behavior

In most cases, the conformance tests can be passed by adding functionality, such as functions and command-line options, to the operating system. As this does not change existing behavior or interfaces, it will not affect current applications (and will not be addressed in this document). For portability, however, new or changed code should use conformant interfaces.

In some cases, the standard defines behavior that was left unspecified by existing documentation, such as manual pages). The tests look for this behavior. In most cases, the changes needed to pass the tests will not affect current applications. In cases where specific problems have been observed, this document discusses them.

In a relatively small number of cases, conformant interfaces or behavior actually conflict with that found in previous (legacy) versions of OS X. As discussed in the compat(5) manual page, OS X v.10.5 provides ways to approximate legacy behavior. Although this does not guarantee that current programs will "Just Work", it should minimize the number of coding changes.

Types of Compatibility Issues

Existing compiled applications should not encounter problems in moving to OS X v.10.5. If a system call or library function is known to have new behavior, the new version will only be used with programs that have been compiled for use on OS X v.10.5. An existing executable will not "see" these versions and thus will not be affected by the changes.

If an application is recompiled for use on OS X v.10.5, it will get the new versions of libraries and system calls, unless a legacy target is specified (See Execution issues, below) .Some scripts, such as bash and perl scripts, may also encounter problems with commands whose options and/or behavior has changed. It is possible to request legacy behavior by setting the environment variable COMMAND_MODE to the value "legacy".

Compile/Link Issues

The include files and/or prototypes for a number of library functions and system calls have changed. If a change seems likely to cause problems, the previous version or versions have been documented in the LEGACY SYNOPSIS section of the relevant manual page.

Although you should use conformant include files and prototypes where possible, the following macro:

#define _NONSTD_SOURCE

will frequently allow the legacy versions to be used. Again, see the compat(5) manual page for details.

The following manual pages currently have LEGACY SYNOPSIS sections:

Command usage issues

If the options and/or behavior of a command have changed significantly, one or more LEGACY sections should document this fact. However, these sections are still very much "in progress" at this time.

The following commands respond to the COMMAND_MODE environment variable, as discussed in compat(5):

Execution issues

SUSv3 requires a number of error checks that the OS X kernel has not made in the past. As a result, unexpected errno values may be encountered. Because specific reason(s) for most of these values have not yet been documented in the relevant manual pages, your best resource is the intro(2) manual page, which supplies general explanations for errno values.

Although some C-language calls now check for error conditions that they didn't under OS X v.10.4, commands and applications compiled for earlier releases of OS X (e.g., OS X v.10.4, OS X v.10.3) will not be affected. The changes take effect only if the programs are recompiled on OS X v10.5 (or greater) with a deployment target of OS X v10.5 (or greater).

The deployment target can be set in at least two ways. One way is to set an environment variable. For example, in bash(1), this would look like this:

export MACOSX_DEPLOYMENT_TARGET=10.5   # Build for use on OS X v.10.5
export MACOSX_DEPLOYMENT_TARGET=10.4   # Build for use on OS X v.10.4
export MACOSX_DEPLOYMENT_TARGET=10.3   # Build for use on OS X v.10.3

Alternatively, the target can be passed to the compiler as a command-line option, as shown here:

gcc -mmacosx-version-min=10.5 ...      # Build for use on OS X v.10.5
gcc -mmacosx-version-min=10.4 ...      # Build for use on OS X v.10.4
gcc -mmacosx-version-min=10.3 ...      # Build for use on OS X v.10.3