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
231
232
233
234
235
236
237
238
239
240
241
|
This is preliminary information about the Macintosh(tm) MPW(tm) port
of the Cygnus GNU tools.
INSTALLING CYGNUS GNU TOOLS
To use these tools, you will need a Mac with a 68020 or better or else
any PowerMac, System 7.1 or later, and MPW 3.3 or 3.4. You will *not*
need MPW C unless you want to rebuild from sources, nor even any
include files, unless you are building actual Mac applications.
The Cygnus GNU tools can go in any directory that is in your
{Commands} list. We generally put all the tools in something like
{Boot}Cygnus:latest:bin, and something like this in a UserStartup
file:
set Commands "{Boot}Cygnus:latest:bin:,{Commands}"
However, the cpp and cc1 programs of GCC are not normally stored here.
Instead, they will be in a "lib" directory that is alongside "bin",
and organized by target and version underneath, with names like
:lib:gcc-lib:<target>:cygnus-<version>:
If you built and installed everything yourself according to the build
instructions, then you will not have any problems. However, you may
discover that GCC seems unable to find the right cpp and cc1; usually
this will be because directory names have changed. (Even renaming
your hard disk will make this happen.) In such cases, you have
several choices. One is just to add this directory to {Commands}, but
then you will not be able to get any other cpp or cc1, such as those
used by a different target or version. Another way is to rename your
disk and directories to match the prefix used when the tools were
compiled. Finally, you can set the variable GCC_EXEC_PREFIX to point
to the library directory:
set GCC_EXEC_PREFIX MyDisk:Stuff:lib:gcc-lib:
export GCC_EXEC_PREFIX
USING CYGNUS GNU TOOLS
To compile and link a file "foo.c", say
gC foo.c
This port of GCC exactly the same option syntax as its Unix
counterpart. It also has similar compilation rules, so it will run
the assembler on .s files and so forth. For the example above, the
output file will be an MPW binary file named "a.out".
The GCC manual includes full information on the available options.
One option that may be especially useful is "-v", which shows you what
tools and options are being used; unlike MPW C, GCC directs assembly
and linking in addition to compilation.
To find standard include files you can set the variable GCCIncludes:
set GCCIncludes MyDisk:MyIncludes:
export GCCIncludes
GCCIncludes is similar to MPW's CIncludes or CW's MWCIncludes. In
order to use MPW's usual include files, just say:
set GCCIncludes "{CIncludes}"
export GCCIncludes
The assembler ("as") and linker ("ld") are faithful ports of their
Unix counterparts. Similarly, the binutils "ar", "cplusfilt", "nm",
"objcopy", "objdump", "ranlib", "size", "strings", and "strip" are all
like they are under Unix. (Note that "cplusfilt" is actually called
"c++filt" under Unix.)
There are two flavors of GDB. "gdb" is an MPW tool that works very
much like it does in Unix; put a command into the MPW worksheet and
type the <enter> key to send it to GDB. While "gdb" is running, you
cannot do anything else in MPW, although you can switch to other
applications and use them.
"SiowGDB" is also a Mac application, but it is GDB using the SIOW
package to provide console emulation. Commands are exactly as for the
MPW tool, but since this is its own application, you can switch
between it and MPW.
Currently, both flavors of GDB can only do cross-debugging, via the
serial port.
BUILDING CYGNUS GNU TOOLS
This port of the Cygnus GNU tools uses a configure script similar to
that used for GNU tools under Unix, but rewritten for MPW. As with
Unix configuration, there is an "object" directory that may be
different from the "source" directory. In the example commands below,
we will assume that we are currently in the object directory, and that
the source directory is "{Boot}Cygnus:src".
In addition to the sources, you will need a set of tools that the
configure and build scripts assume to be available. These tools
(and their versions, if relevant) are as follows:
byacc tool
flex (2.3.7) tool (and Flex.skel file)
forward-include script
MoveIfChange script
mpw-touch script
mpw-true script
null-command script
open-brace script
sed (1.13) tool
tr-7to8 script
true script
The scripts are in the sources, under utils:mpw:. You must arrange to
get the other tools yourself (they are readily available from the
"usual" net sites, and are also on many CDROMS). In addition, there
will usually be a set of these available at ftp.cygnus.com, in pub/mac.
You may put the build tools in your usual Tools or Scripts
directories, or keep them in a separate directories. We prefer to
make a directory called "buildtools" and we put this in our
UserStartup:
set Commands "{Boot}Cygnus:buildtools:,{Commands}"
Flex uses an environment variable FLEX_SKELETON to locate its skeleton
file, so you need to do something like this, preferably in UserStartup:
Set FLEX_SKELETON "{Boot}"Cygnus:buildtools:Flex.skel
Export FLEX_SKELETON
To build everything, setdirectory to the object directory and do:
{Boot}Cygnus:src:mpw-configure --target <name> --cc <compiler> --srcdir {Boot}Cygnus:src: --prefix <whatever>
If the the source directory is not in your {Commands} list, then you must
supply a full pathname to mpw-configure, since mpw-configure invokes
itself after switching into each subdirectory. Using a relative
pathname, even something like ':mpw-configure', will therefore not work.
<name> must be a known target. Valid ones include "m68k-apple-macos",
"powerpc-apple-macos", "i386-unknown-go32", "mips-idt-ecoff", and
"sh-hitachi-hms". Not all target types are accepted for all of the
tools yet.
<compiler> must be the name of the compiler to use. It defaults to "mpwc".
(m68k)
mpwc MPW C
sc68k Symantec C
mwc68k Metrowerks C (Codewarrior)
gcc68k GCC
(powerpc)
ppcc PPCC
mrc Macintosh on RisC (Mister C, aka(?) Frankenstein)
scppc Symantec C
mwcppc Metrowerks C (Codewarrior)
gccppc GCC
Not all compilers will compile all tools equally well! For m68k Macs,
MPW C has the best record so far (it has problems, but they can be
worked around), while for PowerMacs, CodeWarrior is the only compiler
that has successfully compiled everything into running code.
<prefix> is the path that "gcc" will prepend when looking for tools
to execute.
Then the command
mpw-build
will build everything, and
mpw-build install
will install it. Building will take over an hour on a Quadra 800.
If you use CodeWarrior, you *must* set MWCIncludes to {CIncludes}.
This is because you will be building MPW tools, and their standard I/O
works by making references to data that is part of the MPW Shell,
which means that the code must be compiled and linked with macros
that refer to that data, and those macros are in {CIncludes}, not
the default {MWCIncludes}. Without this change, you will encounter
problems compiling libiberty/mpw.c, but tweaking that file only
masks the real problem, and does not fix it.
Most versions of MPW C have problems with compiling GNU software.
MPW C 3.2.x has preprocessing bugs that render it incapable of
compiling the BFD library, so it can't be used at all for building BFD.
MPW C 3.3, 3.3.1, and 3.3.2 will spontaneously claim to have found
errors in the source code, but in fact the code is perfectly fine. If
this happens, just set the working directory back to the top-level
objdir (where the configure command above was performed), and type
"mpw-build all" again. If it goes on through the supposed error, then
you got one of the spurious errors. A full build may require a number
of these restarts.
MPW C 3.3.3 seems to work OK, at least with the aid of a number of
workarounds that are in the sources (look for #ifdef MPW_C).
Versions of MPW Make earlier than 4.0d2 have exhibited bizarre behavior,
failure to substitute variables and the like.
Metrowerks CW6 PPC linker (MWLinkPPC) seems to do bad things with memory
if the "Modern Memory Manager" is turned on (in the Memory control panel),
but works OK if it is turned off.
Metrowerks CW6 loses bigtime compiling opcodes:ppc-opc.c, which has
some deeply nested macros. (CW7 is OK.) There is a way to patch the
file, by substituting constant values. If you need to do this,
contact shebs@cygnus.com for details.
<Gestalt.h> is missing from {CIncludes} in the MPW version that comes
with CW 7. You can just copy the one in CW7's {MWCIncludes}.
KNOWN BUGS
'/' or ' ' embedded in any device, directory, or file name may or may not work.
objcopy -O srec foo.o makes random output filenames.
Mac-x-mips requires -mgas but Unix hosts don't.
GDB will frequently require a '/' on the front of a device name in order
to recognize it as an absolute rather than a relative pathname.
GDB doesn't seem to use the printer port correctly, although it tries.
The cursor doesn't always spin as much as it should. To get elaborate
statistics and warnings about spin rates, add this to UserStartup:
set MEASURE_SPIN all
export MEASURE_SPIN
This is not a bug, but - watch out for cr/nl translation! For instance,
if config/mpw-mh-mpw is not properly translated because it has been
copied or updated separately, then everything will almost build, but
you will get puzzling error messages from make or the compiler.
|
