autoconf
, automake
, or autoheader
, you will probably find that it configures itself without modification (though the resulting configuration may be insufficient). Just run configure
and make
as you would on any other UNIX-based system.configure
script fails because it doesn’t understand the architecture, try replacing the project’s config.sub
and config.guess
files with those available in /usr/share/automake-1.6
. If you are distributing applications that use autoconf, you should include an up-to-date version of config.sub
and config.guess
so that OS X users don’t have to do anything extra to build your project./usr/bin/autoconf
on your project to rebuild the configure
script before it works. OS X includes autoconf in the BSD tools package. Beyond these basics, if the project does not build, you may need to modify your makefile using some of the tips provided in the following sections. After you do that, more extensive refactoring may be required.configure
script with releases, so this is usually not necessary unless you are building an open source project using sources obtained from CVS or from a daily source snapshot./usr/local/
, so you may need to modify your PATH
environment variable to use the newly updated version. Do not attempt to replace the version installed in /usr/
.autoconf
, automake
, and autoheader
.-arch ppc64
and -arch x86_64
to the CFLAGS
and LDFLAGS
.LDFLAGS
to gcc instead of passing them directly to ld, you may need to specify the linker flags as -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk
. This tells the compiler to pass the unknown flags to the linker without interpreting them. Do not pass the LDFLAGS
in this form to ld, however; ld does not currently support the -Wl
syntax.LDFLAGS
to both gcc and ld, you may need to modify it to pass this argument in different forms, depending on which tool is being used. Fortunately, these cases are rare; most makefiles either pass LDFLAGS
to gcc or ld, but not both. Newer versions of gcc support -syslibroot
directly.LDFLAGS
to gcc
or ld
, they may still be passed to one or the other by a make rule. If you are using the standard built-in make rules, the contents of LDFLAGS
are passed directly to ld
. If in doubt, assume that it is passed to ld
. If you get an invalid flag error, you guessed incorrectly.ppc
pass, a ppc64
pass, or an i386
pass). When this happens, the tool must be configured and compiled for each architecture as separate executables, then glued together manually using lipo
.--host
, --build
, and --target
flags. However, this may simply result in defaults for the target platform being inserted, which doesn’t really solve the problem.__BIG_ENDIAN__
and __LITTLE_ENDIAN__
to test endianness at compile time.htonl
, htons
, ntohl
, and ntohs
to guarantee a big-endian representation on any architecture.lowbyte=word & 0xff; nextbyte = (word >> 8) & 0xff;
and so on).int
or long
for a 4-byte piece of data, you should simply use a standard sized type such as uint32_t
.ar
, cannot work with libraries containing code for more than one architecture (or single-architecture libraries generated with lipo
) after ranlib has added a table of contents to them. Thus, if you need to add additional object files to a library, you must keep a separate copy without a TOC.-M
switch to gcc (to output dependency information) is not supported when multiple architectures are specified on the command line. Depending on your makefile, this may require substantial changes to your makefile rules. For autoconf-based configure scripts, the flag --disable-dependency-tracking
should solve this problem.-i
flag to disable dependency checks or put no-dependencies
in the AUTOMAKE_OPTIONS
variable in each Makefile.am file.--target
, --host
, and --build
are not handled gracefully. Different versions also behave differently when you specify only one or two of these flags. Thus, you should always specify all three of these options if you are running an autoconf-generated configure script with intent to cross-compile.config.*
files (and config.guess
in particular) with updated copies from the version of autoconf that comes with OS X./usr/bin/autoconf
. It will automatically detect and use the configure.in
file and use it to generate a new configure script. If you get warnings, you should first try a web search for the error message, as someone else may have already run into the problem (possibly on a different tool) and found a solution.AC_
macros, you may need to download a copy of libraries on which your tool depends and copy their .m4
autoconf configuration files into /usr/share/autoconf
. Alternately, you can add the macros to the file acinclude.m4
in your project’s main directory and autoconf should automatically pick up those macros.automake
and/or autoheader
if your tool uses them. Be prepared to run into missing AM_
and AH_
macros if you do, however. Because of the added risk of missing macros, this should generally only be done if running autoconf by itself does not correct a build problem.CFLAGS
during compilation. However, this behavior is not completely consistent across makefiles from different projects.lipo
, this obviously will not work.mv miniperl miniperl-target; cp /usr/bin/perl miniperl
).#ifdef __MACH__
or #ifdef __APPLE__
to try to determine whether it was being compiled on OS X or not. While this seems appealing as a quick way of getting ported, it ultimately causes more work in the long run. For example, if you make the assumption that a particular function does not exist in OS X and conditionally replace it with your own version that implements the same functionality as a wrapper around a different API, your application may no longer compile or may be less efficient if Apple adds that function in a later version.uname
API), code should never behave differently on OS X merely because it is running on OS X. Code should behave differently because OS X behaves differently in some way—offering an additional feature, not offering functionality specific to another operating system, and so on. Thus, for maximum portability and maintainability, you should focus on that difference and make the conditional compilation dependent upon detecting the difference rather than dependent upon the OS itself. This not only makes it easier to maintain your code as OS X evolves, but also makes it easier to port your code to other platforms that may support different but overlapping feature sets.__i386__
—Intel (32-bit)__x86_64__
—Intel (64-bit)__ppc__
—PowerPC (32-bit)__ppc64__
—PowerPC (64-bit)__BIG_ENDIAN__
—Big endian CPU__LITTLE_ENDIAN__
—Little endian CPU__LP64__
—The LP64 (64-bit) data modelautoconf
, you can create arbitrary conditional compilation on nearly any practical feature of the installation, from testing to see if a file exists to seeing if you can successfully compile a piece of code.main
function calls a function in that framework. If the test program compiles and links successfully, the application framework is present for the specified CPU architecture.poll
does not support device files such as /dev/tty
. If you just avoid poll
if your code is running on OS X, you are making two assumptions that you should not make:poll
on device files. While this is probably true for most device files, not all device files support poll
in all operating systems, so this is also not necessarily a valid assumption.poll
on a device file, and if the call fails, disables the use of poll
. If using poll
provides some significant advantage, it may be better to perform a runtime test early in your application execution, then use poll
only if that test succeeds. By testing for support at runtime, your application can use the poll
API if is supported by a particular version of any operating system, falling back gracefully if it is not supported.CC
environment variable in your Makefile. For example, CC=gcc-4.0
chooses GCC 4.0. In Xcode, you can change the compiler setting on a per-project basis or a per-file basis by selecting a different compiler version in the appropriate build settings inspector.CFLAGS
or LDFLAGS
variable in your makefile, depending on which part of the compiler chain interprets the flags. Unless otherwise specified, you should add these flags to CFLAGS
if needed.-flat_namespace
(in LDFLAGS
)-bundle
(in LDFLAGS
)ld
man page for more discussion of this flag.-bundle_loader
executable (in LDFLAGS
)-framework
framework (in LDFLAGS
)-mmacosx-version-min
version.o
) files. To get more information about the Apple linker read the manual page for ld
.libfoo
, uses another library, libbar
, for its implementation of the function barIt
. Now suppose an application wants to override the use of libbar
with a compressed version, called libzbar
. Since libfoo
was linked against libbar
at compile time, this is not possible without recompiling libfoo
.libfoo
to libbar
, you would use the flag -flat_namespace
. The ld
man page has a more detailed discussion of this flag.-flat_namespace
if you need to override a library’s references to another library.-force_flat_namespace
to tell dyld
to use a flat namespace when loading any dynamic libraries and bundles loaded by the binary. This is usually not necessary, however.libmytool.a
, libmytool.dylib
, or libmytool.so
, for example, all you have to do is this:.a
) except as a temporary side product of building an application. You must run ranlib
on any archive file before you attempt to link against it.dlopen
family of functions. These are described in the man page for dlopen
. The ld
and dyld
man pages give more specific details of the dynamic linker’s implementation..dylib
instead of .so
. You should be aware of this when writing code to load shared code in OS X.libSystem
, that contains much of the core system functionality. This single module provides the standard C runtime environment, input/output routines, math libraries, and most of the normal functionality required by command-line applications and network services.libSystem
library also includes functions that you would normally expect to find in libc and libm, RPC services, and a name resolver. Because libSystem
is automatically linked into your application, you do not need to explicitly add it to the compiler’s link line. For your convenience, many of these libraries exist as symbolic links to libSystem
, so while explicitly linking against -lm
(for example) is not needed, it will not cause an error.glibtool
to avoid a name conflict with NeXT libtool. For more information, see the manual page for glibtool
.-dynamiclib
flag.-bundle
flag.-bundle_loader
flag. For example:must
use the -l
flag to link against any libraries that the plugin requires as though you were building a complete executable./System/Library/Frameworks/CoreFoundation.framework
with the -framework
flag. A more thorough discussion of frameworks is in Mac Technology Overview.-multiply_defined treatment
-twolevel_namespace
is in effect. The values for treatment must be one of:error
—Treat multiply defined symbols as an error.warning
—Treat multiply defined symbols as a warning.suppress
—Ignore multiply defined symbols.-twolevel_namespace
is in effect.-multiply_defined_unused treatment
-twolevel_namespace
is in effect. An unused multiply defined symbol is a symbol defined in the output that is also defined in one of the dynamic libraries, but in which but the symbol in the dynamic library is not used by any reference in the output. The values for treatment must be error
, warning
, or suppress
. The default for unused multiply defined symbols is to suppress these messages.__OBJC__
.m
file or any header included by a .m
file. You can force the Objective-C compiler to be used for a .c
or .h
file by passing the -ObjC
or -ObjC++
flags.__cplusplus
-ObjC++
flag).__ASSEMBLER__
.s
files.__NATURAL_ALIGNMENT__
int
is aligned on sizeof(int)
boundary, a short int is aligned on sizeof(short)
boundary, and so on. It is defined by default when you're compiling code for PowerPC architecutres. It is not defined when you use the -malign-mac68k
compiler switch, nor is it defined on Intel architectures.__MACH__
__APPLE__
__APPLE_CC__
__BIG_ENDIAN__
and __LITTLE_ENDIAN__
__APPLE__
with __MACH__
macros. The macro __UNIX__
is not defined in OS X.alloc.h
stdlib.h
instead. Alternatively, you can define the prototypes yourself as follows:ftw.h
ftw
function traverses through the directory hierarchy and calls a function to get information about each file. However, there isn't a function similar to ftw
in fts.h
.fts_open
, fts_children
, and fts_close
to implement such a file traversal. To do this, use the fts_open
function to get a handle to the file hierarchy, use fts_read
to get information on each file, and use fts_children
to get a link to a list of structures containing information about files in a directory.opendir
, readdir
and closedir
with recursion to achieve the same result./usr/include
using fts.h
, then the code would be as follows:fts
to understand the structures and macros used in the code. The sample code above shows a very simplistic file traversal. For instance, it does not consider possible subdirectories existing in the directory being searched.getopt.h
unistd.h
instead.lcrypt.h
unistd.h
instead.malloc.h
stdlib.h
instead.mm.h
mmap
to map files into memory. If you wish to map devices, use the I/O Kit framework instead.module.h
KextManagerLoadKextWithURL
and related functions. The modules themselves must be compiled against the Kernel framework. For more information, see IOKit Fundamentals.nl_types.h
CFBundleCopyLocalizedString
API in Core Foundation for similar localization functionality.ptms.h
pty
manual page.stream.h
iostream.h
.stropts.h
swapctl.h
swap.h
to implement swap functionality. The swap.h
header file contains many functions that can be used for swap tuning.termio.h
termios.h
, which is part of the POSIX standard. These two header files are very similar. However, the termios.h
does not include the same header files as termio.h
. Thus, you should be sure to look directly at the termios.h
header to make sure it includes everything your application needs.utmp.h
utmpx.h
instead.values.h
limits.h
instead.wchar.h
CFStringRef
API in Core Foundation instead.btowc, wctob
wchar
API, the preferred way to work with international strings is the CFStringRef
API, which is part of the Core Foundation framework. Some of the APIs available in Core Foundation are CFStringGetSystemEncoding
, CFStringCreateCopy
, CFStringCreateMutable
, and so on. See the Core Foundation documentation for a complete list of supported APIs.catopen, catgets, catclose
nl_types.h
is not supported, thus, these functions are not supported. These functions gives access to localized strings. There is no direct equivalent in OS X. In general, you should use Core Foundation to access localized resources (CFBundleCopyLocalizedString
, for example).crypt
crypt
function performs password encryption, based on the NBS Data Encryption Standard (DES). Additional code has been added to deter key search attempts.crypt
. OS X's version of the function crypt
behaves very similarly to the Linux version, except that it encrypts a 64-bit constant rather than a 128-bit constant. This function is located in the unistd.h
header file rather than lcrypt.h
.-lcrypt
is not supported in OS X.dysize
ecvt
, fcvt
sprintf
, snprintf
, and similar functions instead.fcloseall
fclose
. Although OS X supports fclose
, fcloseall
is not supported. You can use fclose
to implement fcloseall
by storing the file pointers in an array and iterating through the array.getmntent
, setmntent
, addmntent
, endmntent
, hasmntopt
/etc/fstab
. However, to the extent that they are, you can get similar functionality from getfsent
and related functions.poll
sbrk
, brk
brk
and sbrk
functions are historical curiosities left over from earlier days before the advent of virtual memory management. Although they are present on the system, they are not recommended.shmget
shmget
has a limited memory blocks allocation. When several applications use shmget
, this limit may change and cause problems for the other applications. In general, you should either use mmap
for mapping files into memory or use the POSIX shm_open
function and related functions for creating non-file-backed shared memory.swapon
, swapoff
ldd
ldd
command is not available in OS X. However, you can use the command otool -L
to get the same functionality that ldd
provides. The otool
command displays specified parts of object files or libraries. The option -L
displays the name and version numbers of the shared libraries that an object file uses. To see all the existing options, see the manual page for otool
.lsmod
lsmod
is not available on OS X, but other commands exist that offer similar functionality. The kextutil
kextstat
kextload
kextutil
instead.kmodunload
kextutil
instead.