/[cmucl]/src/BUILDING
ViewVC logotype

Contents of /src/BUILDING

Parent Directory Parent Directory | Revision Log Revision Log


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

  ViewVC Help
Powered by ViewVC 1.1.5