/[cmucl]/src/BUILDING
ViewVC logotype

Contents of /src/BUILDING

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.22 - (hide annotations)
Sun Aug 1 14:33:45 2010 UTC (3 years, 8 months ago) by rtoy
Branch: MAIN
CVS Tags: release-20b-pre1, release-20b-pre2, RELEASE_20b, snapshot-2010-08
Branch point for: RELEASE-20B-BRANCH
Changes since 1.21: +2 -0 lines
Tell user to use the -h option to get up-to-date info on each
command.
1 toy 1.1 -*- Mode: text -*-
2     Building CMU CL
3     ===============
4    
5     This document is intended to give you a general overview of the build
6     process (i.e. what needs to be done, in what order, and what is it
7     generally called). It will also tell you how to set up a suitable
8     build environment, how the individual scripts fit into the general
9     scheme of things, and give you a couple of examples.
10    
11     General Requirements
12     --------------------
13    
14     In order to build CMU CL, you will need:
15    
16     a) A working CMU CL binary. There is no way around this requirement!
17    
18     This binary can either be for the platform you want to target, in
19     that case you can either recompile or cross-compile, or for another
20     supported platform, in that case you must cross-compile, obviously.
21    
22     b) A supported C compiler for the C runtime code.
23    
24     Most of the time, this means GNU gcc, though for some ports it
25     means the vendor-supplied C compiler. The compiler must be
26     available under the name specified by your ports Config file.
27    
28     c) GNU make
29    
30     This has to be available either as gmake or make in your PATH, or
31     the MAKE environment variable has to be set to point to the correct
32     binary.
33    
34     d) The CMU CL source code
35    
36     Here you can either use one of the release source tarballs, or
37     check out the source code directly from the public CMUCL CVS
38     repository.
39    
40     If you want to build CMU CL's Motif interface/toolkit, you'll need a
41     working version of the Motif libraries, either true-blue OSF/Motif, or
42     OpenMotif, or Lesstif. The code was developed against 1.2 Motif,
43     though recompilation against 2.x Motif probably works as well.
44    
45     Setting up a build environment
46     ------------------------------
47    
48     1.) Create a base directory and change to it
49    
50     mkdir cmucl ; cd cmucl
51    
52     2.) Fetch the sources and put them into the base directory
53    
54 rtoy 1.2 tar xzf /tmp/cmucl-source.tar.gz
55 toy 1.1
56     or, if you want to use the CVS sources directly:
57    
58 rtoy 1.2 export CVSROOT=:pserver:anonymous@common-lisp.net:/project/cmucl/cvsroot
59 toy 1.1 cvs login (password is `anonymous')
60     cvs co src
61    
62     Whatever you do, the sources must be in a directory named src
63     inside the base directory. Since the build tools keep all
64     generated files in separate target directories, the src directory
65     can be read-only (e.g. mounted read-only via NFS, etc.)
66    
67     The build tools are all in the src/tools directory.
68    
69     That's it, you are now ready to build CMU CL.
70    
71 rtoy 1.3 A quick guide for simple builds
72     -------------------------------
73    
74     We recommend that you read all of this document, but in case you don't
75     want to do that and in case you know, somehow, that the version of
76     CMUCL you are building from will build the sources you have, here is a
77     quick guide.
78    
79     a) Simple builds
80    
81     Use this to build from a version of CMUCL that is very close to the
82     sources you are trying to build now:
83    
84     src/tools/build.sh -C "" -o "<name-of-old-lisp> <options-to-lisp>"
85    
86     This will build CMUCL 3 times, each time with the result of the
87     previous build. The last time, the additional libraries like CLX,
88     CLM, and Hemlock are built. The final result will be in the
89     directory build-4.
90    
91     This script basically runs create-target.sh, build-world.sh,
92     load-world.sh three times. See below for descriptions of these
93     scripts.
94    
95     b) Slightly more complicated builds
96    
97     For slightly more complicated builds, you may need to use some
98     bootstrap files. See below for more information about these
99     bootstrap files.
100    
101     For these, you can use this:
102    
103     src/tools/build.sh -C "" -o "<old-lisp>" -B boot1.lisp -B boot2.lisp
104    
105     The bootstrap files listed with the -B option (as many as needed)
106     are loaded in order, so be sure to get them right.
107    
108     As in a) above, three builds are done, and the result is in the
109     directory build-4.
110    
111     c) More complicated builds
112    
113     If you have more complicated builds, this script probably will not
114     work, and definitely does not handle cross-compiles. In this case,
115     you will have to invoke the individual scripts by hand, as
116     described below.
117    
118     How do you know which of the three options above apply? The easiest
119     way is to look in src/bootfiles/<version>/* for boot files. If the
120     file date of a boot file is later than the version of CMUCL you are
121     building from, then you need to use b) or c) above. You may need to
122     read the bootfiles for additional instructions, if any.
123    
124     If there are no bootfiles, then you can use a) above.
125    
126     The build.sh script supports other options, and src/tools/build.sh -?
127     will give a quick summary. Read src/tools/build.sh for more
128     information.
129 toy 1.1
130     A general outline of the build process
131     --------------------------------------
132    
133     Building CMU CL can happen in one of two ways: Normal recompilation,
134     and cross-compilation. We'll first look at normal recompilation:
135    
136     The recompilation process basically consists of 4 phases/parts:
137    
138     a) Compiling the lisp files that make up the standard kernel.
139    
140     This happens in your current CMU CL process, using your current
141     CMU CL's normal file compiler. This phase currently consists of 3
142     sub-phases, namely those controlled by src/tools/worldcom.lisp,
143     which compiles all the runtime files, src/tools/comcom.lisp, which
144     compiles the compiler (including your chosen backend), and finally
145     src/tools/pclcom.lisp, which compiles PCL, CMU CL's CLOS
146     implementation. The whole phase is often called "world-compile",
147     or "compiling up a world", based on the name of the first
148     sub-phase.
149    
150     b) Building a new kernel.core file out of the so created files
151    
152     This process, which is generally called genesis, and which is
153     controlled by src/tools/worldbuild.lisp, uses the newly compiled
154     files in order to build a new, basic core file, which is then used
155     by the last phase to create a fully functional normal core file.
156     It does this by "loading" the compiled files into an in-core
157     representation of a new core file, which is then dumped out to
158     disk, together with lots of fixups that need to happen once the new
159     core is started.
160    
161     As part of this process, it also creates the file internals.h,
162     which contains information about the general memory layout of the
163     new core and its basic types, their type tags, and the location of
164     several important constants and other variables, that are needed by
165     the C runtime code to work with the given core.
166    
167     So going through genesis is needed to create internals.h, which is
168     needed to compile the C runtime code (i.e. the "lisp" binary).
169     However there is a slight circularity here, since genesis needs as
170     one of its inputs the file target:lisp/lisp.nm, which contains the
171     (slightly pre-treated) output of running nm on the new lisp
172     binary. Genesis uses this information to fixup the addresses of C
173     runtime support functions for calls from Lisp code.
174    
175     However the circularity isn't complete, since genesis can work with
176     an empty/bogus lisp.nm file. While the kernel.core it then
177     produces is unusable, it will create a usable internals.h file,
178     which can be used to recompile the C runtime code, producing a
179     usable lisp.nm file, which in turn can be used to restart genesis,
180     producing a working kernel.core file.
181    
182     Genesis also checks whether the newly produced internals.h file
183     differs from a pre-existing internals.h file (this might be caused
184     by an empty internals.h file if you are rebuilding for the first
185     time, or by changes in the lisp sources that cause differences in
186     the memory layout of the kernel.core), and informs you of this, so
187     that you can recompile the C runtime code, and restart genesis.
188    
189     If it doesn't inform you of this, you can skip directly to the last
190     phase d).
191    
192     c) Recompiling the C runtime code, producing the "lisp" binary file
193    
194     This step is only needed if you haven't yet got a suitable lisp
195     binary, or if the internals.h file has changed during genesis (of
196     which genesis informs you), or when you made changes to the C
197     sources that you want to take effect.
198    
199     Recompiling the C runtime code is controlled by a GNU Makefile, and
200     your target's Config file. It depends on a correct internals.h
201     file as produced by genesis.
202    
203     Note that whenever you recompile the runtime code, for whatever
204     reason, you must redo phase b). Note that if you make changes to
205     the C sources and recompile because of this, you can do that before
206     Phase b), so that you don't have to perform that phase twice.
207    
208     d) Populating the kernel.core, and dumping a new lisp.core file.
209    
210     In this phase, which is controlled by src/tools/worldload.lisp, and
211     hence often called world-load, the kernel.core file is started up
212     using the (possibly new) lisp binary, the remaining files which
213     were compiled in phase a) are loaded into it, and a new lisp.core
214     file is dumped out.
215    
216 rtoy 1.2 We're not quite done yet. This produces just a basic lisp.core.
217     To complete the build so that you something similar to what the
218     releases of CMUCL do, there are a few more steps:
219    
220     e) Build the utilities like Gray streams, simple streams, CLX, CLM,
221     and Hemlock. Use the src/tools/build-utils.sh script for this, as
222     described below
223    
224     f) Create tarfiles using the src/tools/make-dist.sh script, as
225     explained below.
226    
227     With these tarfiles, you can install them anywhere. The contents of
228     the tarfiles will be the same as the snapshots and releases of CMUCL.
229    
230 toy 1.1 When cross-compiling, there is additional phase at the beginning, and
231     some of the phases happen with different hosts/platforms. The initial
232     phase is setting up and compiling the cross-compilation backend, using
233     your current compiler. The new backend is then loaded, and all
234     compilation in phase a) happens using this compiler backend. The
235     creation of the kernel.core file in phase b) happens as usual, while
236     phase c) of course happens on the target platform (if that differs
237     from the host platform), as does the final phase d). Another major
238     difference is that you can't compile PCL using the cross-compiler, so
239     one usually does a normal rebuild using the cross-compiled core on the
240     target platform to get a full CMU CL core.
241    
242     So, now you know all about CMU CL compilation, how does that map onto
243     the scripts included with this little text?
244    
245     Overview of the included build scripts
246     --------------------------------------
247    
248 rtoy 1.2 * src/tools/create-target.sh target-directory [lisp-variant [motif-variant]]
249 toy 1.1
250     This script creates a new target directory, which is a shadow of the
251     source directory, that will contain all the files that are created by
252     the build process. Thus, each target's files are completely separate
253     from the src directory, which could, in fact, be read-only. Hence you
254     can simultaneously build CMUCL for different targets from the same
255     source directory.
256    
257     The first argument is the name of the target directory to create. The
258     remaining arguments are optional. If they are not given, the script
259     tries to determine the lisp variant and motif variant from the system
260     the script is running on.
261    
262     The lisp-variant (i.e. the suffix of the src/lisp/Config.* to use as
263     the target's Config file), and optionally the motif-variant (again the
264     suffix of the src/motif/server/Config.* file to use as the Config file
265     for the target's CMUCL/Motif server code). If the lisp-variant is
266     given but the motif-variant is not, the motif-variant is determined
267     from the lisp-variant.
268    
269     The script will generate the target directory tree, link the relevant
270     Config files, and generate place-holder files for various files, in
271     order to ensure proper operation of the other build-scripts. It also
272     creates a sample setenv.lisp file in the target directory, which is
273     used by the build and load processes to set up the correct list of
274     *features* for your target lisp core.
275    
276     IMPORTANT: You will normally NOT have to modify the sample setenv.lisp
277     file, if you are building from a binary that has the desired features.
278     In fact, the sample has all code commented out, If you want to add or
279     remove features, you need to include code that puts at least a minimal
280     set of features onto the list (use PUSHNEW and/or REMOVE). You can
281     use the current set of *features* of your lisp as a first guide. The
282     sample setenv.lisp includes a set of features that should work for the
283     intended configuration. Note also that some adding or removing some
284     features may require a cross-compile instead of a normal compile.
285    
286 rtoy 1.2 * src/tools/clean-target.sh [-l] target-directory [more dirs]
287 toy 1.1
288     Cleans the given target directory, so that all created files will be
289     removed. This is useful to force recompilation. If the -l flag is
290     given, then the C runtime is also removed, including all the lisp
291     executable, any lisp cores, all object files, lisp.nm, internals.h,
292     and the config file.
293    
294 rtoy 1.2 * src/tools/build-world.sh target-directory [build-binary] [build-flags...]
295 toy 1.1
296     Starts a complete world build for the given target, using the lisp
297     binary/core specified as a build host. The recompilation step will
298     only recompile changed files, or files for which the fasl files are
299     missing. It will also not recompile the C runtime code (the lisp
300     binary). If a (re)compilation of that code is needed, the genesis
301     step of the world build will inform you of that fact. In that case,
302     you'll have to use the rebuild-lisp.sh script, and then restart the
303     world build process with build-world.sh
304    
305 rtoy 1.2 * src/tools/rebuild-lisp.sh target-directory
306 toy 1.1
307     This script will force a complete recompilation of the C runtime code
308     of CMU CL (aka the lisp executable). Doing this will necessitate
309     building a new kernel.core file, using build-world.sh.
310    
311 rtoy 1.2 * src/tools/load-world.sh target-directory version
312 toy 1.1
313     This will finish the CMU CL rebuilding process, by loading the
314     remaining compiled files generated in the world build process into the
315     kernel.core file, that also resulted from that process, creating the
316     final lisp.core file.
317    
318     You have to pass the version string as a second argument. The dumped
319     core will anounce itself using that string. Please don't use a string
320     consisting of an official release name only, (e.g. "18d"), since those
321     are reserved for official release builds. Including the build-date in
322     ISO8601 format is often a good idea, e.g. "18d+ 2002-05-06" for a
323     binary that is based on sources current on the 6th May, 2002, which is
324     post the 18d release.
325    
326 rtoy 1.2 * src/tools/build-utils.sh target-directory
327 toy 1.1
328     This script will build auxiliary libraries packaged with CMU CL,
329     including CLX, CMUCL/Motif, the Motif debugger, inspector, and control
330     panel, and the Hemlock editor. It will use the lisp executable and
331     core of the given target.
332    
333 rtoy 1.2 * src/tools/make-dist.sh [-bg] [-G group] [-O owner] target-directory version arch os
334 toy 1.1
335     This script creates both main and extra distribution tarballs from the
336     given target directory, using the make-main-dist.sh and
337 rtoy 1.2 make-extra-dist.sh scripts. The result will be two tar files. One
338     contains the main distribution including the runtime and lisp.core
339     with PCL (CLOS); the second contains the extra libraries such as
340     Gray-streams, simple-streams, CLX, CLM, and Hemlock.
341    
342     Some options that are available:
343    
344     -b Use bzip2 compression
345     -g Use gzip compression
346     -G group Group to use
347     -O owner Owner to use
348    
349     If you specify both -b and -g, you will get two sets of tarfiles. The
350     -G and -O options will attempt to set the owner and group of the files
351     when building the tarfiles. This way, when you extract the tarfiles,
352     the owner and group will be set as specified. You may need to be root
353     to do this because many Unix systems don't normally let you change the
354     owner and group of a file.
355    
356     The remaining arguments used to create the name of the tarfiles. The
357     names will have the form:
358    
359     cmucl-<version>-<arch>-<os>.tar.bz2
360     cmucl-<version>-<arch>-<os>.extras.tar.bz2
361    
362     Of course, the "bz2" will be "gz" if you specified gzip compression
363     instead of bzip.
364    
365     * /src/tools/make-main-dist.sh target-directory version arch os
366 toy 1.1
367 rtoy 1.2 This is script is not normally invoked by the user; make-dist will do
368     it appropriately.
369 toy 1.1
370     This script creates a main distribution tarball (both in gzipped and
371     bzipped variants) from the given target directory. This will include
372     all the stuff that is normally included in official release tarballs
373     such as lisp.core and the PCL libraries, including Gray streams and
374     simple streams.
375    
376     This is intended to be run from make-dist.sh.
377    
378 rtoy 1.2 * src/tools/make-extra-dist.sh target-directory version arch os
379    
380     This is script is not normally invoked by the user; make-dist will do
381     it appropriately.
382 toy 1.1
383     This script creates an extra distribution tarball (both in gzipped and
384     bzipped variants) from the given target directory. This will include
385     all the stuff that is normally included in official extra release
386     tarballs, i.e. the auxiliary libraries such as CLX, CLM, and Hemlock.
387    
388     This is intended to be run from make-dist.sh.
389    
390    
391     * cross-build-world.sh target-directory cross-directory cross-script
392     [build-binary] [build-flags...]
393    
394     This is a script that can be used instead of build-world.sh for
395     cross-compiling CMUCL. In addition to the arguments of build-world.sh
396     it takes two further required arguments: The name of a directory that
397     will contain the cross-compiler backend (the directory is created if
398     it doesn't exist, and must not be the same as the target-directory),
399     and the name of a Lisp cross-compilation script, which is responsible
400     for setting up, compiling, and loading the cross-compiler backend.
401     The latter argument is needed because each host/target combination of
402     platform's needs slightly different code to produce a working
403     cross-compiler.
404    
405     We include a number of working examples of cross-compiler scripts in
406     the cross-scripts directory. You'll have to edit the features section
407     of the given scripts, to specify the features that should be removed
408     from the current set of features in the host lisp, and those that
409     should be added, so that the backend features are correct for the
410     intended target.
411    
412     You can look at Eric Marsden's collection of build scripts for the
413     basis of more cross-compiler scripts.
414    
415     Step-by-Step Example of recompiling CMUCL for OpenBSD
416     -----------------------------------------------------
417    
418     Set up everything as described in the setup section above. Then
419     execute:
420    
421     # Create a new target directory structure/config for OpenBSD:
422     src/tools/create-target.sh openbsd OpenBSD_gencgc OpenBSD
423    
424     # edit openbsd/setenv.lisp to contain what we want:
425     cat <<EOF > openbsd/setenv.lisp
426     ;;; Put code to massage *features* list here...
427    
428     (in-package :user)
429    
430     (pushnew :openbsd *features*)
431     (pushnew :bsd *features*)
432     (pushnew :i486 *features*)
433     (pushnew :mp *features*)
434     (pushnew :hash-new *features*)
435     (pushnew :random-mt19937 *features*)
436     (pushnew :conservative-float-type *features*)
437     (pushnew :gencgc *features*)
438    
439     ;;; Version tags
440    
441     (pushnew :cmu18d *features*)
442     (pushnew :cmu18 *features*)
443     (setf *features* (remove :cmu17 *features*))
444     (setf *features* (remove :cmu18c *features*))
445     EOF
446    
447     # Recompile the lisp world, and dump a new kernel.core:
448     src/tools/build-world.sh openbsd lisp # Or whatever you need to invoke your
449     # current lisp binary+core
450    
451     # If build-world tells you (as it will the first time) that:
452     # "The C header file has changed. Be sure to re-compile the startup
453     # code."
454     # You 'll need to start rebuild-lisp.sh to do that, and then reinvoke
455     # build-world.sh:
456    
457     # Recompile lisp binary itself:
458     src/tools/rebuild-lisp.sh openbsd
459    
460     # Restart build-world.sh now:
461     src/tools/build-world.sh openbsd lisp
462    
463     # Now we populate the kernel.core with further compiled files,
464     # and dump the final lisp.core file:
465    
466     src/tools/load-world.sh openbsd "18d+ 2002-05-06"
467    
468     # The second argument above is the version number that the built
469     # core will announce. Please always put the build-date and some
470     # other information in there, to make it possible to differentiate
471     # those builds from official builds, which only contain the release.
472    
473     Now you should have a new lisp.core, which you can start with
474    
475     ./openbsd/lisp/lisp -core ./openbsd/lisp/lisp.core -noinit -nositeinit
476    
477     Compiling sources that contain disruptive changes
478     -------------------------------------------------
479    
480     The above instructions should always work as-is for recompiling CMU CL
481     using matching binaries and source files. They also work quite often
482     when recompiling newer sources. However, every so often, some change
483     to the CMU CL sources necessitates some form of bootstrapping, so that
484     binaries built from earlier sources can compile the sources containing
485     that change. There are two forms of boostrapping that can be
486     required:
487    
488     a) Bootfiles
489    
490     The maintainers try to make bootfiles available, that allow going
491     from an old release to the next release. These are located in the
492     src/bootfiles/<old-release>/ directory of the CMU CL sources.
493    
494     I.e. if you have binaries that match release 18d, then you'll need
495     to use all the bootfiles in src/bootfiles/18d/ in order to go to
496     the next release (or current sources, if no release has been made
497     yet). If you already used some of the bootstrap files to compile
498     your current lisp, you obviously don't need to use those to get to
499     later versions.
500    
501     You can use the bootfiles by concatenating them into a file called
502     bootstrap.lisp in the target directory (i.e. target:bootstrap.lisp)
503     in the order they are numbered. Be sure to remove the bootstrap
504     file once it is no longer needed.
505    
506 rtoy 1.2 Alternatively, the bootstrap file can just "load" the individual
507     bootfiles as needed.
508 toy 1.1
509     b) Cross-compiling
510    
511     Under some circumstances, bootstrap code will not be sufficient,
512     and a cross-compilation is needed. In that case you will have to
513     use cross-build-world.sh, instead of build-world.sh. Please read
514     the instructions of that script for details of the more complex
515     procedure.
516    
517     << This isn't really true anymore, and we should place a more
518     elaborate description of the cross-compiling process here >>
519    
520     When cross-compiling, there are two sorts of bootscripts that can be
521     used: Those that want to be executed prior to compiling and loading
522     the cross-compiler, which should be placed in the file called
523     target:cross-bootstrap.lisp, and those that should happen after the
524     cross-compiler has been compiled and loaded, just prior to compiling
525     the target, which should be placed in target:bootstrap.lisp, just
526     like when doing a normal recompile.
527    
528     Additionally, sometimes customized cross-compiler setup scripts
529     (to be used in place of e.g. cross-x86-x86.lisp) are required,
530     which are also placed in one of the bootfiles/*/* files. In those
531     cases follow the instructions provided in that file, possibly merging
532     the changed contents thereof with your normal cross-script.
533    
534     Step-by-Step Example of Cross-Compiling
535     ---------------------------------------
536    
537     This gives a step-by-step example of cross-compiling a sparc-v8 build
538     using a sparc-v9 build. (For some unknown reason, you can't just
539     remove the :sparc-v9 feature and add :sparc-v8.)
540    
541     So, first get a recent sparc-v9 build. It's best to get a version
542     that is up-to-date with the sources. Otherwise, you may also need to
543     add a bootstrap file to get any bootfiles to make your lisp
544     up-to-date with the current sources.
545    
546 rtoy 1.2 1. Select a directory for the cross-compiler and compiled target:
547    
548     Create a cross-compiler directory to hold the cross-compiler
549     and a target directory to hold the result:
550    
551     src/tools/create-target.sh xcross
552     src/tools/create-target.sh xtarget
553    
554     2. Adjust cross-compilation script
555    
556     Copy the src/tools/cross-scripts/cross-sparc-sparc.lisp to
557     xtarget/cross.lisp. Edit it appropriately. In this case, it
558     should look something like:
559 toy 1.1
560 rtoy 1.2 (c::new-backend "SPARC"
561     ;; Features to add here
562     '(:sparc :sparc-v8
563     :complex-fp-vops
564     :linkage-table
565     :gencgc
566     :stack-checking
567     :relative-package-names
568     :conservative-float-type
569     :hash-new :random-mt19937
570     :cmu :cmu19 :cmu19a
571     )
572     ;; Features to remove from current *features* here
573     '(:sparc-v9 :sparc-v7 :x86 :x86-bootstrap :alpha :osf1 :mips
574     :propagate-fun-type :propagate-float-type :constrain-float-type
575     :openbsd :freebsd :glibc2 :linux :pentium
576     :long-float :new-random :small))
577 toy 1.1
578 rtoy 1.2 (setf *features* (remove :sparc-v9 *features*))
579     (pushnew :sparc-v8 *features*)
580 toy 1.1
581 rtoy 1.2 It's important to add frob *features* here as well as in the
582     new-backend. If you don't adjust *features*, they won't be
583     set appropriately in the result.
584 toy 1.1
585 rtoy 1.2 3. Build the cross compiler and target
586     Now compile the result:
587 toy 1.1
588 rtoy 1.2 src/tools/cross-build-world.sh xtarget xcross xtarget/cross.lisp [v9 binary]
589 toy 1.1
590 rtoy 1.2 4. Rebuild the lisp files:
591 toy 1.1
592 rtoy 1.2 When this finishes, you need to compile the C code:
593 toy 1.1
594 rtoy 1.2 src/tools/rebuild-lisp.sh xtarget
595 toy 1.1
596 rtoy 1.2 At this point, you may want to run cross-build-world.sh again
597     to generate a new kernel.core. It shouldn't build anything;
598     just loads everything and creates a kernel.core.
599 toy 1.1
600 rtoy 1.2 5. Build the world:
601 toy 1.1
602 rtoy 1.2 With the new kernel.core, we need to create a lisp.core:
603 toy 1.1
604 rtoy 1.2 src/tools/load-world.sh xtarget "new lisp"
605 toy 1.1
606 rtoy 1.2 Test the result with
607 toy 1.1
608 rtoy 1.2 xtarget/lisp/lisp -noinit
609 toy 1.1
610 rtoy 1.2 However, this lisp will be missing some functionality like PCL. You
611     probably now want to use the compiler to rebuild everything once
612     again. Just follow the directions for a normal build, and use
613     xtarget/lisp/lisp as your compiler. Be sure to use create-target.sh
614     to create a new directory where the result can go.
615 toy 1.1
616 rtoy 1.4 Cross-Platform Cross-Compile
617     ----------------------------
618    
619     A cross-platform cross-compile is very similar to a normal
620     cross-compile, and the basic steps are the same. For the sake of
621     concreteness, assume we are on ppc/darwin and want to cross-compile
622     to x86/linux.
623    
624     To simplify things, we assume that both platforms have access to the
625     same file system, via NFS or something else.
626    
627     1. As above, we need to create directories for the cross-compiler and
628     compiled target. We assume we are on ppc/darwin. So, when running
629 rtoy 1.6 create-target.sh we need to specify the target:
630    
631     src/tools/create-target.sh x86-cross x86
632     src/tools/create-target.sh x86-target x86
633 rtoy 1.4
634     2. Adjust the cross-compilation script. An example for ppc/darwin to
635     x86/linux is in src/tools/cross-scripts/cross-ppc-x86.lisp.
636    
637     3. Build the cross compiler and target, as above, using the specified
638 rtoy 1.7 cross-compile script:
639    
640     src/tools/cross-build-world.sh x86-target x86-cross cross.lisp [ppc binary]
641    
642     where cross.lisp is the cross-compile script from 2) above.
643 rtoy 1.4
644     4. Everything has now been compiled for the x86/linux target. We need
645     to compile the C code for x86 and create a lisp.core from the
646     kernel.core. This is where it's useful to have both platforms be
647     able to access the same file system. If not, you will need to copy
648     all of the generated files from ppc/darwin to x86/linux. Basically
649     everything in xtarget needs to be copied.
650    
651     Note carefully that you may have to edit lisp/internals.h and/or
652     lisp/internals.inc to have the correct features. This is a known
653     bug in the generation of these files during cross-compilation.
654 rtoy 1.8
655     Compile the lisp code:
656    
657     src/tools/rebuild-lisp.sh x86-target
658 rtoy 1.4
659     5. Now run load-world.sh to create the desired lisp.core from lisp and
660     kernel.core. As above, PCL has not been compiled, so select
661     restart 3 (return nil from pclload) to create lisp.core
662    
663 rtoy 1.9 src/tools/load-world.sh x86-target "new x86"
664    
665 rtoy 1.4 At this point, you will have a shiny new lisp on the new platform.
666     Since it's missing PCL, you will need to do at least one normal build
667     to get PCL included. This is also a good check to see if everything
668     was compiled properly. A full set of builds via build.sh might be
669     good at this point too.
670 rtoy 1.19
671 rtoy 1.22 Some of the details for each command may have changed; You can get
672     help for each command by using the -h argument.

  ViewVC Help
Powered by ViewVC 1.1.5