pkgsrc/bootstrap/README.MacOSX
gdt 0a5272fd89 Fix a typo and s/Mac OS X/OS X/g
Thanks to wiz@ and Luis Muir for pointing these out.
2015-11-06 16:38:27 +00:00

153 lines
5.5 KiB
Text

$NetBSD: README.MacOSX,v 1.22 2015/11/06 16:38:27 gdt Exp $
This file describes the use of current versions of pkgsrc with
multiple versions of OS X, omitting information about previous pkgsrc
versions. (Apple has renamed Mac OS X to OS X, but the filename
remains.)
* system tools issues
** native headers vs SDK
OS X used to include system headers in /usr/include, so that one
could treat it like a relatively normal POSIX system. Starting at
approximately 10.9, headers were no longer available at the standard
location, and one has to use an SDK that puts headers someplace else.
pkgsrc supports this, but there has been some confusion where a 10.9
system produced binaries for 10.10, which only mostly works. The
confusion is believed to be resolved.
** gcc vs clang
Older versions of OS X (when XCode is installed) provided gcc, and
pkgsrc defaulted to using gcc. With 10.9, gcc is no longer present.
** i386 vs x86_64 ABI issue
OS X 10.6 and higher supports x86-64 binaries on most Intel Macs.
This has caused problems with packages which get confused because
"MACHINE_ARCH" is in some OS versions set to "i386" (on a 64-bit
system!).
version: uname -m : uname -p
10.6: i386 : i386
10.9: x86_64 : i386
On Intel machines, pkgsrc currently defaults to i386 mode (--abi=32)
on OS X, and can be set to x86_64 mode (--abi=64).
Note that a pkgsrc build in x86_64 mode will not run on an Intel Mac
that is i386 only (some older Mac Minis and Macbooks). For a longer
discussion, see:
http://mail-index.NetBSD.org/pkgsrc-users/2009/09/24/msg010817.html
As of 2015-11, changing the default to x86_64 is imminent.
** sed in 10.9
The sed that comes with 10.9 appears to be broken; it exits when
called on files with UTF-8 or other apparently-binary content.
Therefore, pkgsrc uses nbsed on 10.9.
* Developer tools and prerequisites
** XCode
This section applies to 10.6 through 10.10.
If you haven't already, you will need to install the OS X
Developer Tools package (XCode) to obtain a compiler, etc. The
procedure depends on the version of OS X; recent versions use the
App Store.
** Command-line Tools
In 10.11, XCode has been reported as unsuitable [TODO: add details,
but it seems it doesn't include an SDK for itself]. Instead, it is
recommend to install command-line tools.
** cvs
Note that as of 10.9, cvs is no longer provided by Apple. You can build
devel/scmcvs. To obtain pkgsrc in order to bootstrap and build cvs,
it may be useful to `git clone https://github.com/jsonn/pkgsrc.git`.
** X11
X11 used to be built into OS X, but as of 10.8 it is no longer
included. Install XQuartz from http://xquartz.macosforge.org/landing/
* OS X Versions
pkgsrc is a volunteer project, and individuals support/fix packages
and platforms as they choose. However, pkgsrc contributors as a group
share both a bugtracker and norms about what is ok to break and what
is not. To describe these norms, we define levels of concern, keeping
in mind that there are no guarantees:
SUPPORTED doesn't mean that anyone is required to fix your problem; it
means that we agree that it is broadly desireable that such problems
be fixed and that we therefore allow them to be listed in our issue
tracker. Structural breakage is unacceptable.
DEPRECATED means that individual problems are not of interest, but
pkgsrc overall working is of enough interest to be allowed to be
listed in the issue tracker. Structural breakage is undesirable,
but a fair topic of discussion if keeping support is painful.
Individual pkg PRs may be bounced to authors to retest with newer
versions, and closed if that doesn't happen in 14 days.
IGNORED means we are not willing to expend issue tracker resources
(clutter for those reviewing the db) at all. PRs may be summarily
closed. We are also unconcerned with whether pkgsrc works on the
system at all.
Given the above definitions, the pkgsrc developers label versions of
OS X as follows:
10.11: current. [SUPPORTED]
10.10: recent. [SUPPORTED]
10.9 (13.4.0): somewhat old but not that crufty. [SUPPORTED]
10.8: old. [SUPPORTED]
10.7: old. [SUPPORTED]
10.6 (10.8.0): very old [DEPRECATED] (But note that this is the
Joyent i386-mode build target.)
10.5 and below: ancient, and PRs will be summarily closed. It is
acceptable to give zero consideration to causing structural
problems on 10.5 and below. [IGNORED]
Because Apple provides 10.9 as a no-cost upgrade (from 10.6 or higher,
it is fairly likely that 10.6-10.8 will become DEPRECATED faster than
they might have otherwise. (The rationale for supporting versions
beyond the current and previous ones has been the difficulty for users
to upgrade.)
* Bulk builds
Clearly, it is desirable for a bulk build to be useful on as many
computers as possible. The main issues are which ABI and which OS X
version. Targetting older versions makes a build run on more systems,
and targetting newer versions makes the build closer to what would be
obtained from bootstrappping on a newer version and thus avoids some
issues.
** 10.6, --abi=32 (i386), gcc
Joyent provide a bulk build for quarterly branches (--abi=32, OSX
10.6, and therefore gcc 4.2.1, XQuartz, X11_TYPE=native):
http://pkgsrc.joyent.com/install-on-osx/
which should run on any version from 10.6 and up.
Note that sed on 10.9 is broken, but a bootstrap on 10.6 will not
avoid it, so while one can install this bootstrap on 10.9 and run
binary packages, building packages will not in general work.
** 10.9, --abi=64 (x86-64), clang
Joyent provide a bulk build for 10.9/x86_64, and therefore clang, at
the same URL as above.