« back to all changes in this revision
Viewing changes to src/README.txt
- browse files at revision 7
- compare with another revision
- download diff
- download tarball
- view history from revision 7
- Committer: Bazaar Package Importer
- Author(s): Chris Hanson
- Date: 2006-09-20 21:59:42 UTC
- mfrom: (1.1.4 upstream) (3.1.1 etch)
- Revision ID: james.westby@ubuntu.com-20060920215942-o3erry1wowyk1ezz
Tags: 7.7.90+20060906-3
No changes; rebuild with downgraded openssl in order to permit
transition into testing.
transition into testing.
- files added:
- debian/watch
- icons
- src/runtime-check/http-client.bin
- src/runtime-check/srfi-1.bin
- files removed:
- src/autom4te.cache
- src/microcode/autom4te.cache
- files modified:
- debian/changelog
added
removed
src/README.txt
1
1
Structure and construction of the MIT/GNU Scheme source tree
2
2
3
$Id: README.txt,v 1.4 2004/12/07 04:54:47 cph Exp $
3
$Id: README.txt,v 1.5 2006/06/02 07:46:03 ihtfisp Exp $
4
4
5
5
Directories
6
6
===========
53
53
* "edwin" contains our Emacs-like editor written in Scheme.
54
54
55
55
* "imail" contains an email-reading program for Edwin.
56
56
57
57
These are miscellaneous extras:
58
58
59
59
* "6001" is extra code used here at MIT for teaching 6.001, our
88
88
* "wabbit" contains program for finding all of the objects that
89
89
contain pointers to a given object.
90
90
91
Building from source on unix systems
91
Building from source on unix systems - ``The Easy Way''
92
92
====================================
93
93
94
94
Building MIT/GNU Scheme from the CVS sources is a multi-stage process.
125
125
configured distribution make distclean
126
126
configured CVS make maintainer-clean
127
127
128
The following sequence of commands can be used to rebuild MIT
129
Scheme from the CVS sources and install it:
128
The following sequence of commands can be used to rebuild MIT/GNU
129
Scheme from the CVS sources and install it, assuming that some binary
130
release corresponding to the CVS sources has already been installed:
130
131
131
132
./Setup.sh
132
133
./configure
136
137
Note that the "./Setup.sh" command requires a compiler that supports
137
138
the "-M" option for generating dependencies. Normally this step is
138
139
executed on a GNU/Linux system.
140
141
The above should suffice for building from the CVS sources when some
142
binary release corresponding to the CVS sources has been successfully
143
obtained, unpacked and confirmed to run without errors. When not,
144
some modest manual configuration is called for. The next few sections
145
address this eventuality, why it might arise and how to overcome it.
146
147
Building from source on unix systems - ``The Hard Way''
148
====================================
149
150
These more detailed build instructions cover the case where no binary
151
release corresponding to the CVS sources runs successfully on your
152
system or none can be installed in the usual system-wide location(s).
153
154
If you don't care to understand the underlying issues, skip ahead to
155
the next section, which is a step-by-step ground-up methodology for
156
installing MIT/GNU Scheme from scratch from the CVS sources. If
157
anything goes wrong in that effort, however, you may need to return
158
here to understand what went wrong and what might be tried to fix it.
159
160
The Problem
161
-----------
162
163
So why does MIT/GNU Scheme fail to install without the corresponding
164
binary release first being installed? (And how do you overcome that?)
165
166
In short, to transition a pristine checked out CVS source tree
167
installation from the ``maintainer-clean'' CVS build state into the
168
``distribution'' build state, the "./Setup.sh" uses MIT/GNU Scheme
169
itself to grovel over the Scheme sources to build up Scheme system
170
file dependencies and other distribution-specific configuration data.
171
172
This means that in order to invoke "./Setup.sh" successfully, you must
173
first already have some runnable version of MIT/GNU Scheme available.
174
175
Why
176
---
177
178
So why might a binary release distribution fail to run on your system?
179
180
This may occur if your system's dynamic library modules (like `glibc')
181
do not match those against which the binary release was built or if
182
you simply do not have permission to install software packages in the
183
usual place(s) on your system.
184
185
It also may arise if the installed version of MIT/GNU Scheme on your
186
system does not match the version you are trying to build from the CVS
187
sources but you cannot (or prefer not to) uninstall it and replace it
188
with the matching version (as when release 7.6 is installed but you're
189
trying to build 7.7 sources while you or others on your system still
190
depend on the older version being installed for other projects, etc.).
191
192
How
193
---
194
195
A few simple environment variable settings are normally sufficient to
196
work around these difficulties but on rare occasion some more serious
197
manual preparations will be required. Specifically, if you cannot
198
successfully run _any_ MIT/GNU Scheme binaries then you will need to
199
skip to the next section first: ``MIT/GNU Scheme Tabula Rasa''.
200
201
Before delving into details, some high-level explanation is in order.
202
203
What
204
----
205
206
The CVS sources ship in `maintainer-clean' configuration. This means
207
that no generated "Makefile" nor "configure" files are present nor are
208
any C or Scheme compiled files. Additionally, various infrastructure
209
symbolic links used to identify the operating system and/or family of
210
microprocessor are not yet in place in the CVS tree build directory.
211
212
The combination of invoking "./Setup.sh" followed by "configure"
213
addresses these, as described in the build transition table in the
214
previous section.
215
216
Alas, going from the "CVS" build state to the "distribution" build
217
state requires running a general tool over various file configuration
218
tables to set up various file dependency lists and system-dependent
219
Makefile directives and so forth. As you may have already guessed,
220
the general tool used to do this in the MIT/GNU Scheme CVS tree is
221
MIT/GNU Scheme itself.
222
223
Naturally, this results in a bit of a chicken-and-egg puzzle.
224
225
The Rub
226
-------
227
228
In a nutshell, both the "./Setup.sh" command and the "make" invocation
229
prescribed earlier require the availability of: 1) _some_ executable
230
MIT/GNU Scheme ``microcode'' file (usually named "scheme"), as well as
231
2) the base companion MIT/GNU Scheme microcode table ("utabmd.bin")
232
and run-time band for that microcode release. (named "runtime.com").
233
234
Moreover, in the case of the "make" invocation, we also require an
235
MIT/GNU Scheme run-time compiler band ("compiler.com" or "all.com")
236
containing the MIT/GNU Scheme native compiler so it can compile the
237
run-time system. Otherwise, the entire system run-time would be
238
running interpreter-only (including the compiler itself). Although
239
that may be a necessary evil on a platform for which the compiler has
240
not yet been ported (like on an EDSAC or an FTL nano-processor based
241
system), the default "make" directive assumes you want to compile the
242
run-time library and tools (including the MIT Scheme compiler itself).
243
244
Friction
245
--------
246
247
Due to various release (in)compatibility issues--- such as re-named
248
internal system procedures, the hygienic macro system re-write, or
249
re-factored interfaces on internal system modules--- it is not
250
normally possible to build a given release (say, 7.7) from sources by
251
using an incompatible installed release (say, 7.6).
252
253
It is, however, often possible to build MIT/GNU Scheme from the ground
254
up from the sources even when the corresponding binaries are not fully
255
installed.
256
257
Naturally, this process is a bit delicate. It does require that
258
_some_ binary release has at least been obtained and unpacked, even if
259
the binary executable cannot be run (e.g., due to dynamic library
260
incompatibilities and the like, such as `glibc' versions, &c.) and
261
even if you do not have file system permissions to install software in
262
the usual system-wide locations (like `/usr/local/' or `/usr/share/').
263
264
The details of this modestly complicated process follow.
265
266
Building from source on unix systems - Not using an installed Scheme
267
====================================
268
269
There are two classes of complication that may occur when trying to
270
build MIT/GNU Scheme from scratch:
271
272
If you can obtain, unpack and successfully run some binary release
273
of MIT/GNU Scheme but you cannot install it in the usual place
274
then you may be able to do a ``warm'' build.
275
276
If, however, no obtainable binary MIT/GNU Scheme release package
277
successfully runs on your system--- e.g., due to their having
278
been built with dynamic libraries (like `glibc') that do not
279
match your particular system installation--- then a relatively
280
simple microcode ``cold'' build is required first.
281
282
Since a ``warm'' build is probably more common, we describe it first.
283
We're optimistic that way.
284
285
286
``Warm'' build using matching binary and source releases
287
--------------------------------------------------------
288
289
[0]. Obtain the appropriate binary release for the source you have.
290
291
The first step is to obtain the base "runtime.com" and "all.com"
292
run-time bands, the "scheme" executable (``microcode'') that
293
corresponds to the release we wish to build from the CVS sources,
294
and the microcode table ("utabmd.bin") and sundry other MIT/GNU
295
Scheme library support files (in `lib/mit-scheme/').
296
297
For instance, if the CVS sources are for the Scheme release 7.7.1
298
branch, then you require `mit-scheme-7.7.1-<cpu>-<ostype>.tar.gz'
299
for your system.
300
301
If the "scheme" executable (``microcode'') from these obtained
302
binaries cannot run successfully on your system, you must resort
303
to the ``cold'' build procedure detailed below.
304
305
The next step diagnoses if that is the case for your system.
306
307
[1]. Verify that the binary release runs on your system.
308
309
Binary releases contain: 1) a `bin/' directory containing the
310
executable ``microcode'' (usually named "scheme"), and: 2) a
311
`lib/mit-scheme/' directory containing the run-time bands for
312
that microcode (along with some other goodies). You should
313
verify that these microcode and run-time binaries run on your
314
system before going any further.
315
316
You do that as follows...
317
318
[1a]._____
319
First, assume the unpacked `bin' and `lib' directories are both
320
immediate subdirectories of a directory whose absolute pathname
321
is defined by the environment variable MITSCHEME_BOOTSTRAP_DIR.
322
323
This is mainly for expository convenience and purity of essence.
324
325
For example, type something like one of the following into your
326
interactive shell, depending on which shell you use and where you
327
placed the untar'd binaries:
328
329
(ba)sh:
330
export MITSCHEME_BOOTSTRAP_DIR="$HOME/testing/scheme-7.7.1"
331
332
export MITSCHEME_MICROCODE_DIR = \
333
"${MITSCHEME_BOOTSTRAP_DIR}/bin"
334
335
export MITSCHEME_EXECUTABLE = \
336
"${MITSCHEME_MICROCODE_DIR}/scheme"
337
338
(t)csh:
339
setenv MITSCHEME_BOOTSTRAP_DIR "$HOME/testing/scheme-7.7.1"
340
341
setenv MITSCHEME_MICROCODE_DIR \
342
"${MITSCHEME_BOOTSTRAP_DIR}/bin"
343
344
setenv MITSCHEME_EXECUTABLE \
345
"${MITSCHEME_MICROCODE_DIR}/scheme"
346
347
Please note that none of these bindings end in a `/' character.
348
349
These are just convenience variables we define to help clarify
350
the following presentation. You may name them whatever you like
351
or simply type in full absolute file pathnames in place of their
352
appearances in what follows. Season to taste.
353
354
[1b].____
355
Next, you must define the standard internally-referenced Scheme
356
environment variable MITSCHEME_LIBRARY_PATH to point to the
357
`lib/mit-scheme/' subdirectory of the binary release directory,
358
for example, by typing something like one of the following:
359
360
(ba)sh:
361
export MITSCHEME_LIBRARY_PATH = \
362
"${MITSCHEME_BOOTSTRAP_DIR}/lib/mit-scheme"
363
(t)csh:
364
setenv MITSCHEME_LIBRARY_PATH \
365
"${MITSCHEME_BOOTSTRAP_DIR}/lib/mit-scheme"
366
367
Please note that these bindings do not end in a `/' character.
368
369
This environment variable is _not_ merely for convenience: it
370
is a built-in environment variable that Scheme probes on entry.
371
It is how we tell the microcode where to find its companion
372
run-time bands and support files when they are not yet installed.
373
374
[1c].____
375
Last, you are now prepared to verify that this binary release
376
runs correctly on your system by typing the following at your
377
interactive shell prompt:
378
379
${MITSCHEME_EXECUTABLE} -no-init-file
380
381
The `-no-init-file' is to avoid incompatibility distractions in
382
case you have a "$HOME/.scheme.init" file for some other release.
383
384
[Footnote: Future releases may eventually require two leading
385
dashes (as `--no-init-file') but, for backward compatibility, one
386
dash is maximally compatible for now. Similarly throughout the
387
rest of this discussion, we will always show one-dash argument
388
``switches''. Use two-dash switches if this causes any obvious
389
problems here in the future.]
390
391
If you encounter an error message complaining about a library not
392
being found, you cannot use this binary ``microcode'' on your
393
system. You may try again with a different binary release or you
394
can embrace fate and resort to a ``cold'' build (see below).
395
396
Once loaded, try evaluating something trivial (like: 0 or #t
397
followed by carriage [RETURN] or [ENTER]) to verify that it has
398
loaded successfully and can evaluate constants.
399
400
Then try something like: (* 5 4 3 2 1) then maybe: (pp pp)
401
for laughs, and maybe: (gc-flip 0) for kicks. Finally, quit by
402
typing: (exit)
403
404
These simple tests verify, respectively, that the microcode can
405
load, that the microcode and the run-time band are compatible,
406
that the library path points to compiler-compatible debugging
407
info files--- in case anything goes wrong down stream, it helps
408
to see what--- and, finally, that the band's heap is stable.
409
410
If this generates an error about an incompatibility between the
411
microcode and runtime then double check your work above since the
412
microcode and runtime directories shipped in a binary release are
413
always compatible. One telltale of this problem is when Scheme
414
crashes with a segmentation fault (SIGSEGV) within the critical
415
section of the garbage collection daemon.
416
417
Assuming the above has all succeeded, you may now begin the warm
418
build process proper, which is only a slight generalization of
419
that described in the multi-stage build transition table earlier.
420
421
422
This concludes Step [1] (``Verify that the binary release runs.'').
423
424
Once it has been verified that the microcode runs and that the
425
run-time library is consistent with it, you are prepared to start the
426
CVS build's bootstrapping process. The adventure continues!
427
428
[2]. Run "./Setup.sh" from the CVS `src' dir using bootstrap binaries.
429
430
BUT FIRST...
431
432
First, you must define a new shell environment variable used to
433
bootstrap the build process, since MIT/GNU Scheme uses a few
434
Scheme scripts and shell scripts during the `Setup.sh' and `make'
435
processes to lift itself up by its bootstraps. Specifically, you
436
must define:
437
438
(ba)sh:
439
export SCHEME_LARGE = \
440
"${MITSCHEME_EXECUTABLE} -large -no-init-file"
441
(t)csh:
442
setenv SCHEME_LARGE \
443
"${MITSCHEME_EXECUTABLE} -large -no-init-file"
444
445
This tells the build scripts where the "scheme" executable file
446
lives and how to invoke it with a large heap size. If it is not
447
defined, the build scripts will use the first "scheme" found in
448
your shell execution path (shell variable PATH) instead.
449
450
Setting the SCHEME_LARGE environment variable gives us control
451
over which "scheme" to use without having to perturb the normal
452
PATH setting or, worse, squirreling things away early in your
453
normal PATH search sequence.
454
455
This new environment variable is used only by the build scripts:
456
please do not confuse it with the normal MIT/GNU Scheme built-in
457
environment variables named MITSCHEME_LARGE_(CONSTANT|HEAP|STACK)
458
which are run-time, not build-time, configuration parameters.
459
460
With this defined appropriately, invoking "./Setup.sh" should
461
succeed. Look carefully at the output it generates to verify
462
that it succeeded in generating the microcode Makefiles. I.e.,
463
the call to `generate-makefile' should not have yielded an error.
464
465
If this fails then the binaries you're using are not compatible
466
with the CVS sources you are trying to build. If you are using
467
the current stable binary release with the current CVS tree then
468
please send a bug report via the Project GNU bug tracking system
469
for MIT/GNU Scheme [ http://www.gnu.org/software/mit-scheme/ ] as
470
this might reflect an incompatibility in the development branch.
471
472
[3]. Run "./configure" from the CVS `src' directory.
473
474
This does not require a Scheme executable so it should always
475
succeed. If not, please send a bug report as described in the
476
preceding step.
477
478
[4]. Invoke "make" from the CVS `src' dir using newly built microcode.
479
480
BUT FIRST...
481
482
Now you must define a small set of shell environment variables
483
used to bootstrap the Scheme run-time compilation process.
484
Specifically, you must define (while positioned within the CVS
485
`src' directory):
486
487
(ba)sh:
488
export MITSCHEME_LIBRARY_PATH = \
489
"${MITSCHEME_BOOTSTRAP_DIR}/lib/mit-scheme"
490
491
export SCHEME_LARGE = \
492
"${PWD}/microcode/scheme -large -heap 4000 -no-init-file"
493
494
export SCHEME_COMPILER = \
495
"${PWD}/microcode/scheme -compiler -heap 4000 -no-init-file"
496
497
(t)csh:
498
setenv MITSCHEME_LIBRARY_PATH \
499
"${MITSCHEME_BOOTSTRAP_DIR}/lib/mit-scheme"
500
501
setenv SCHEME_LARGE \
502
"${PWD}/microcode/scheme -large -heap 4000 -no-init-file"
503
504
setenv SCHEME_COMPILER \
505
"${PWD}/microcode/scheme -compiler -heap 4000 -no-init-file"
506
507
Please note that this uses the bootstrap binary run-time files
508
(as before) but with the newly generated microcode produced by
509
compiling the CVS sources in the `src/microcode/' directory _and_
510
with a Scheme heap size large enough to handle the entire build.
511
512
This works because the run-time bands do not depend on dynamic
513
system libraries (like `glibc') or other low-level bits and
514
pieces. Specifically, run-time bands must be compatible with
515
the underlying microcode versions atop which they run but the
516
run-time bands do not link directly into the microcode file (nor
517
vice versa) so they are functionally coupled but not bit-wise
518
coupled nor directly linked at the object code level. This is
519
the purpose of the "utabmd.bin" file in `lib/'.
520
521
Together, these tell the build scripts where the new CVS "scheme"
522
microcode file will be made, how to invoke it with a very large
523
heap size and/or with the native code compiler loaded (both with
524
sufficient heap space to compile the entire CVS `src/runtime/'
525
contents), and where to find compatible run-time and compiler
526
bands to use while compiling this new CVS run-time and again
527
while loading then dumping various pre-defined collections of
528
these newly compiled run-time files constituting the various
529
run-time ``bands'' built in the CVS `lib/' subdirectory.
530
531
Finally, please note that "make" will compile the entire run-time
532
library, compiler sources, and other auxiliary Scheme modules.
533
534
This takes a fairly long time and produces a copious amount of
535
output chatter. It may be wise, therefore, to copy its output
536
and error streams into a files that can be inspected afterward to
537
look for any non-fatal warnings or non-show-stopping errors that
538
may nonetheless be symptomatic of problems that might bite later.
539
Using your shell's output redirection compatibilities or piping
540
the output(s) through the unix `tee' utility should prove useful.
541
542
[5]. Cleaning up loose ends... and maybe installing your new build.
543
544
[5a].__________
545
To install...
546
547
If you would now like to install this newly built MIT/GNU Scheme
548
as the system-wide default, type the following:
549
550
make install
551
552
Afterward, before proceeding, take care to clean up the various
553
shell environment variables used during the directed build.
554
555
Depending on which interactive shell you use, do one of these
556
(but _only_ if you typed `make install' above):
557
558
(ba)sh:
559
unset MITSCHEME_BOOTSTRAP_DIR
560
unset MITSCHEME_MICROCODE_DIR
561
unset MITSCHEME_EXECUTABLE
562
unset MITSCHEME_LIBRARY_PATH
563
unset SCHEME_LARGE
564
unset SCHEME_COMPILER
565
566
(t)csh:
567
unsetenv MITSCHEME_BOOTSTRAP_DIR
568
unsetenv MITSCHEME_MICROCODE_DIR
569
unsetenv MITSCHEME_EXECUTABLE
570
unsetenv MITSCHEME_LIBRARY_PATH
571
unsetenv SCHEME_LARGE
572
unsetenv SCHEME_COMPILER
573
574
[5b]._________________
575
Or not to install...
576
577
If, rather than installing the newly built MIT/GNU Scheme, you
578
prefer to use it in place (or somewhere else), be sure to adjust
579
the various environment variables accordingly.
580
581
In particular, take special care to snap MITSCHEME_LIBRARY_PATH
582
to point to your newly compiled library (with no trailing `/'):
583
584
(ba)sh:
585
export MITSCHEME_LIBRARY_PATH = "${PWD}/lib"
586
(t)csh:
587
setenv MITSCHEME_LIBRARY_PATH "${PWD}/lib"
588
589
Note, however, that in order to invoke your new Scheme microcode,
590
your will have to use either its absolute pathname, a relative
591
path name relative to what working directory you are in when you
592
invoke it, or else invoke it as $SCHEME_LARGE or $SCHEME_COMPILER
593
(thereby continuing to use the environment variables established
594
to finish the build). You may also choose to install symbolic
595
links in your exec PATH to point it or other such shenanigans.
596
597
Good luck and happy hacking!
598
599
Building from source on unix systems - ``MIT/GNU Scheme Tabula Rasa''
600
====================================
601
602
Context: A ``binary'' release includes only: 1) a `bin/' directory
603
containing the MIT/GNU Scheme ``microcode'' executable(s),
604
and: 2) the `lib/mit-scheme/' directory containing the
605
MIT/GNU Scheme ``runtime'' bands, debugging info, and such
606
that correspond to that version of the companion microcode.
607
Binary releases do not contain source code files.
608
609
Fact: Although the ``runtime'' files are system-independent, the
610
microcode file(s) are linked against dynamic OS libraries.
611
This means that a binary microcode release may fail to run
612
on your specific machine if it has missing or incompatible
613
dynamic libraries installed (like, in `/usr/include/').
614
615
Question: What can you do when the "scheme" microcode from a binary
616
release cannot be run on your system, perhaps due to old
617
or missing or incompatible dynamic system libraries, etc.?
618
619
Answer: Build the (C-based) "scheme" microcode from the separately
620
distributed CPU+OS-specific source distribution. Afterward
621
you can use this new locally-built microcode in combination
622
with the corresponding binary release's run-time library.
623
624
Insight: The key trick idea is that any given version of the MIT/GNU
625
Scheme runtime library is built to run atop a corresponding
626
release of the MIT/GNU Scheme microcode but they are only
627
functionally coupled, not low-level bit-wise coupled at the
628
link layer or any such nightmare. This means you can brew
629
your own custom executable microcode specific to your CPU
630
and OS configuration from the ``ucode'' source distribution
631
and it will still work with the pre-compiled binary release
632
of the matching runtime library from the binary releases.
633
(By the way, this flexible linkage is accomplished courtesy
634
of the "utabmd.bin" file in `lib/'. Thank you, "utabmd"!)
635
636
Details: Following is a bit more context and detail followed by the
637
instructions for building just the MIT/GNU Scheme microcode
638
file(s) from sources, step by step. You may prefer to skip
639
directly to the enumerated step-by-step instructions if you
640
don't care about the gory details of what you're doing or
641
why. Ignorance = Bliss.
642
643
The following describes how to build a compatible microcode for the
644
binary release corresponding to the CVS sources. In order to be
645
explicit, it presumes that the target binary release is Release 7.7.1
646
on an Intel x86 compatible system running GNU/Linux. Adjust what
647
follows appropriately for other releases, CPUs and/or unix variants.
648
649
For example, one might reasonably prefer to bootstrap from the most
650
recent "snapshot" instead of the most recent "stable" release, in
651
which case one would replace `mit-scheme-7.7.1' below with something
652
like `mit-scheme-20060414' [http://www.gnu.org/software/mit-scheme/].
653
654
This also presumes that your goal is merely to build a given binary
655
release's microcode file(s) locally, not to install them system wide.
656
To that end, it does not contain the usual Step #6: make install
657
from the normal build state transition ritual.
658
659
The idea is to build the microcode corresponding to the target binary
660
release, doing so manually and separately from both the CVS tree and
661
the binary release tree. This task is accomplished by downloading,
662
unpacking and building the target microcode from (non-CVS) sources
663
then copying the resulting microcode into your unpacked binary release
664
directory structure, replacing the non-runnable microcode file(s) with
665
the manually built ones built specially for your system.
666
667
Once done, the resulting patched binary release directory can be used
668
as in a normal ``warm'' build from CVS sources. In other words, at
669
the end of the following action list, go to step [1] (not [0]) of the
670
``warm'' build instructions and proceed from there as usual.
671
672
That being said, ...
673
674
``Cold'' build using non-matching binary and CVS source releases
675
----------------------------------------------------------------
676
677
[Adapted from: http://www.gnu.org/software/mit-scheme/other-unix.html]
678
679
1. Download the standard binary package for your release, CPU & unix
680
(e.g., mit-scheme-7.7.1-ix86-gnu-linux.tar.gz) and the sources
681
(e.g., mit-scheme-7.7.1-src-ucode.tar.gz). The _full_ sources
682
(e.g., mit-scheme-7.7.1-src.tar.gz) also works but that's overkill.
683
684
2. Unpack the source package and `cd' to it's `src/microcode/' subdir:
685
686
tar xzf mit-scheme-7.7.1-src-ucode.tar.gz
687
688
cd scheme-7.7.1/src/microcode/
689
690
3. Configure the microcode directory (from `src/microcode/'):
691
692
./configure
693
694
By having downloaded the microcode source distribution for a
695
specific MIT/GNU Scheme release, CPU and unix variant, we avoid the
696
need to run "src/Setup.sh" to go from the "CVS" build state to the
697
"distribution" build state. (Once fully built, our resulting local
698
microcode can then be used to advance the CVS source directory from
699
its unpacked "CVS" state to its "distribution" state in order to
700
proceed building the full MIT/GNU Scheme system. This buys us the
701
needed bootstrapping leverage to proceed where we might otherwise
702
have failed due to lack of a compatible binary microcode release.)
703
704
4. Compile the program (from `src/microcode/'):
705
706
make
707
708
Note that, being in the unpacked `src/microcode/' directory, only
709
the microcode is built, not any run-time or compiler or other
710
files, so not bootstrapping MIT/GNU Scheme is needed (yet). To
711
wit, those parts of the total CVS build that would have required a
712
bootstrapping MIT/GNU Scheme are sidestepped here since: 1) the
713
microcode table set up is anticipated in the release+CPU+unix-
714
specific source distribution, and: 2) the microcode-only "make"
715
invocation terminates without going on to try to compile any
716
run-time or other Scheme files. In short, building the microcode
717
entails only compiling C code, not mucking about with Scheme code.
718
719
5. Unpack the standard binary package (if you hadn't already done so
720
in the ``warm'' build step #0 above) and copy your newly built
721
microcode executables into it:
722
723
cd ../../..
724
725
tar xzf mit-scheme-7.7.1-ix86-gnu-linux.tar.gz # If not already
726
727
cp -fp scheme-7.7.1/src/microcode/scheme bin/.
728
cp -fp scheme-7.7.1/src/microcode/bchscheme bin/.
729
730
Clobbering/replacing the copies of the binary release microcode
731
file(s) shouldn't disturb you since, presumably, the main reason
732
you resorted to a ``cold'' build in the first place is that the
733
normal binary release microcode wouldn't run anyway (or at least
734
wasn't as obsessively tuned to your exact system as you imagine
735
you'd like it to be).
736
737
Now proceed from step #1 (not #0) of the ``warm'' build instructions
738
above to finish building from the CVS sources.
739
740
And good luck!
Loggerhead is a web-based interface for Breezy
Version: 2.0.1