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
|
$NetBSD: README.MacOSX,v 1.17 2014/03/18 01:28:26 gdt Exp $
* system tools issues
** gcc vs clang
Older versions of Mac OS X (with XCode, of course) provided gcc, and
pkgsrc defaulted to using gcc. With 10.9, gcc is no longer present
and one must bootstrap with "--compiler=clang". (Arguably, pkgsrc
should default to clang on 10.9.)
** i386 vs x86_64 ABI issue
Mac OS X Snow Leopard (10.6) through Mavericks (10.9) supports 64-bit
binaries on most Intel Macs and build those by default on such
machine. 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
There are of course some packages which will fail in i386 mode, and
some in x86_64 mode. Because of all this, the default for pkgsrc was
set to use the 32-bit ABI, which results in packages being compiled
and run in i386 mode. In addition, there are some Intel Macs (older
Mac Minis) which can only run i386 and not x86_64. For a longer
discussion, see:
http://mail-index.NetBSD.org/pkgsrc-users/2009/09/24/msg010817.html
As of 2014, the decision to default to i386 should probably be
revisited.
** 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
** basic tools
If you haven't already, you will need to install the Mac OS X
Developer Tools package (XCode) to obtain a compiler, etc. The
procedure depends on the version of Mac OS X; recent versions use the
App Store.
Note that as of 10.9, cvs is no longer provided. You can build
devel/scmcvs. To obtain pkgsrc in order to bootstrap and build cvs,
it may be useful to use git to clone https://github.com/jsonn/pkgsrc
** X11
X11 used to be built into Mac OS X, but as of 10.8 it is not.
Install XQuartz from http://xquartz.macosforge.org/landing/
** XL compiler
[The text in this section dates from 2004-10-07! Please update it if
you have used XL since then.]
Experimental support for IBM's XL C/C++ compiler is present (tested
with version 6.0). To use it, set:
PKGSRC_COMPILER=xlc
in mk.conf. XL C uses the Apple provided libtool to create shared
libraries, however, we must force it to call libtool with the full
path to avoid calling the pkgsrc provided GNU libtool with arguments
that it does not understand.
edit the template configuration file /opt/ibmcmp/vac/6.0/etc/vac.base.cfg
and set:
libtool = /usr/bin/libtool
then run:
/opt/ibmcmp/vacpp/6.0/bin/vacpp_configure -gcc /usr -install -force
as root to install the configuration.
to bootstrap with xlc, you need to make sure CFLAGS contains "-ma":
env CC=/opt/ibmcmp/vacpp/6.0/bin/xlc CFLAGS=-ma ./bootstrap
* Mac 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.
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.
IGNORED means we are not willing to expend issue tracker resources
(clutter for those reviewing the db) at all.
Given the above definitions, the pkgsrc developers label versions of
Mac OS X as follows:
10.9 (13.1.0): current, PRs may be filed. Structurally breaking
pkgsrc on 10.9 is considered not ok. [SUPPORTED]
10.8: somewhat old, PRs may still be filed. Structurally breaking
pkgsrc on 10.8 is considered not ok. [SUPPORTED]
10.7: old, but PRs may still be filed. Structurally breaking pkgsrc
on 10.7 is considered not ok. [SUPPORTED]
10.6 (10.8.0): very old, and individual pkg PRs may be bounced to
authors to retest with newer versions, and closed if that
doesn't happen in 14 days. We will for now consider
structurally breaking pkgsrc on 10.6 to be undesirable. If
keeping support for 10.6 causes excessive work for maintainers
it may be moved to IGNORED state any time, without
warning. [DEPRECATED]
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 build suggestions and issues
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.
** 10.6, --abi=32
jperkin@netbsd.org provides a bulk build for quarterly branches
(--abi=32, OSX 10.6, and therefore gcc 4.2.1, XQuartz,
X11_TYPE=native):
http://www.perkin.org.uk/pages/pkgsrc-binary-packages-for-osx.html
http://mail-index.netbsd.org/pkgsrc-bulk/2014/01/10/msg010276.html
which should run on any version from 10.6 to 10.9.
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 --compiler=clang
Given the 10.9 license situation, a bulk build on 10.9 (and therefore
clang) seems reasonable, with either --abi=32 or --abi=64. Such
builds are almost certainly only usable on 10.9, but that is or will
be soon a large fraction of Macs.
|
