1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
|
$NetBSD: README.MacOSX,v 1.33 2017/01/09 16:19:28 sevan Exp $
This file describes the use of current versions of pkgsrc with
multiple versions of Darwin and OS X, omitting information about previous pkgsrc
versions.
* Darwin vs OS X
(Apple has renamed Mac OS X to OS X, but the filename
remains.)
OS X consists of Darwin (kernel/userland) plus Mac stuff on top.
pkgsrc used to target Darwin, but given the tools issued discussed
below it is not clear that it works on Darwin without OS X. Darwin
from Apple is no longer open source.
Users of non-OS X Darwin are invited to submit patches to this file.
The only known project is:
http://www.puredarwin.org/
Until then, this file remains OS X-centric.
* OS X specific bootstrap arguments
Providing the --binary-macpkg flag to the bootstrap script causes it
to prepare a bootstrap kit as a native OS X package instead of using
the conventional .tar.bz2 format. This requires the package-maker
application to be installed.
* 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
This entire section is only about Intel Macs.
OS X 10.6 and higher supports x86-64 binaries on Intel Macs with
x86-64 processors, which is now most of them. i386 binaries are also
supported on most (all?) Intel machines.
*** issues related to ABI 32 vs 64
Note that a pkgsrc package built in x86_64 mode will not run on an
Intel Mac that is i386 only. For a longer discussion, see:
http://mail-index.NetBSD.org/pkgsrc-users/2009/09/24/msg010817.html
Somewhat separately from pkgsrc's ABI choice, there have been issues
with packages which get confused because "MACHINE_ARCH" is in some OS
versions set to "i386" (on a 64-bit system!). As of 2016 this should
be mostly resolved.
version: uname -m : uname -p
10.6: i386 : i386
10.9: x86_64 : i386
*** default ABI
The ABI is chosen at bootstrap time and encoded into mk.conf. So a
change in the default is about what a new bootstrap will do;
already-bootstrapped systems should remain unchanged. They should be
able to build and run new packages using the old ABI value.
pkgsrc used to set the default ABI as i386, both on systems with i386
processors and on systems with x86_64 processors. On 2015-11-09 the
default was changed so that ABI=64 is chosen on machines where "uname
-m" reports x86_64. (It remains i386 on others, which are not capable
of running x86_64 binaries.)
Generally, users will not need to deal with the default ABI change,
except that packages are mostly only portable across machines with the
same bootstrapping parameters.
If one unpacks a new binary bootstrap kit over an existing
installation, one can end up with a mix. The standard advice is not to
do this, and to rrebuild/reinstall all packages from scratch or a
compatible binary package set. But, one could also mark packages with
the wrong ABI as rebuild=YES and use pkg_rolling-replace.
*** change in storage of ABI information
On 2016-01-24, the way ABI information was stored in pkgsrc was
rationalized and simplified. The new code could compute the wrong ABI
for some previously-bootstrapped installations. The problem can be
resolved by building bmake with MACHINE_ARCH=x86_64 and updating that
package, as described in mail archives:
https://mail-index.netbsd.org/pkgsrc-users/2016/01/25/msg022870.html
(One would expect to be able to use make replace to do this. One
minor issue is that it requires pkg_tarup, although that will be
present on systems of those who use make replace. There also may be
an error with architecture mismatch from pkg_install requiring a "-f"
option. Repeatable data about recovery is somewhat hard to obtain, as
most are past this issue already and no longer interested in
experimenting.)
** 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.
Command Line Tools for Xcode can be obtained from
https://developer.apple.com/downloads/
Since Xcode 7 (installed from the Apple Store) the development
environment can upgrade itself without interaction from the user, but
will not automatically update the Command Line Tools. This will
cause system header files like stdlib.h not to be found by pkgsrc.
The command `xcode-select --install' will install the Command Line
Tools for Xcode.
** 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. You can install XQuartz from
https://www.xquartz.org, or try the newly-added pkgsrc
version.
* OS X Versions
Because Apple drops support for previous hardware faster than the
hardware fails, many machines cannot be upgraded to recent versions of
OS X, creating a greater than usual desire to support old systems.
Because of the particular history of deprecation, most systems tend to
run relatively recent versions or specific older versions (10.6 and
10.5).
The stance of pkgsrc is generally to avoid breaking older systems
unless keeping support would cause difficulty, and to accept clean
patches when there is no harm to non-deprecated versions. This
section is partly to document what versions tend to be used and why,
and partly to enable cleaning up bug reports without fixes for very
old systems.
pkgsrc PRs about 10.5 or older that do not contain fixes may be closed
without fixing.
OS X 10.11 is considered new and there may be issues.
OS X 10.10 is considered current.
OS X 10.9 (Darwin 13.4.0) is considered current.
OS X 10.8 is old, and there are no no known reasons to it instead of a
newer version.
OS X 10.7 is the last version that works on a few Intel Macs, e.g. the
Mac Pro 1.1 and 2.1 and some Mac Minis.
OS X 10.6 is the last version that works on Intel Macs lacking amd64
support, e.g. Mac Minis and Macbooks with Core Duo. (There is an
active bulk build for 10.6.)
OS X 10.5 is the last version that works on PowerPC Macs. As of 2015
reports of using 10.5 are very rare.
OS X 10.4 (Darwin 8.11.0) is the last version that works on PowerPC G3
and slower G4 Macs.
* 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. Targeting older versions makes a build run on more systems,
and targeting newer versions makes the build closer to what would be
obtained from bootstrapping on a newer version and thus avoids some
issues. This section has pointers to active bulk builds.
** 10.4, --abi=32 powerpc, gcc
Sevan Janiyan <Sevan@NetBSD.org> provides a bulk build for the -current branch
(--abi=32, OS X 10.4/PowerPC, gcc 4.0.1 from Xcode 2.5, X11_TYPE=modular):
https://www.geeklan.co.uk/?p=1579
US repo: http://sevan.mit.edu/packages
Euro mirror: http://pkgsrc.geeklan.co.uk/packages/current/Darwin-8
See
https://mail-index.netbsd.org/pkgsrc-bulk/2015/11/07/msg012171.html
** 10.6, --abi=32 i386, gcc
Joyent provide a bulk build for quarterly branches (--abi=32, OS X
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.
|