/[cmucl]/src/BUILDING
ViewVC logotype

Contents of /src/BUILDING

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.24 - (show annotations)
Wed May 11 14:20:27 2011 UTC (2 years, 11 months ago) by rtoy
Branch: MAIN
CVS Tags: GIT-CONVERSION, snapshot-2011-09, snapshot-2011-06, snapshot-2011-07, HEAD
Changes since 1.23: +6 -0 lines
Add short description for build.sh.
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 tar xzf /tmp/cmucl-source.tar.gz
55
56 or, if you want to use the CVS sources directly:
57
58 export CVSROOT=:pserver:anonymous@common-lisp.net:/project/cmucl/cvsroot
59 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 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
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 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 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 * src/tools/build.sh [-123obvuBCU?]
249
250 This is the main build script. It essentially calls the other build
251 scripts described below in the proper sequence to build cmucl from an
252 existing binary of cmucl.
253
254 * src/tools/create-target.sh target-directory [lisp-variant [motif-variant]]
255
256 This script creates a new target directory, which is a shadow of the
257 source directory, that will contain all the files that are created by
258 the build process. Thus, each target's files are completely separate
259 from the src directory, which could, in fact, be read-only. Hence you
260 can simultaneously build CMUCL for different targets from the same
261 source directory.
262
263 The first argument is the name of the target directory to create. The
264 remaining arguments are optional. If they are not given, the script
265 tries to determine the lisp variant and motif variant from the system
266 the script is running on.
267
268 The lisp-variant (i.e. the suffix of the src/lisp/Config.* to use as
269 the target's Config file), and optionally the motif-variant (again the
270 suffix of the src/motif/server/Config.* file to use as the Config file
271 for the target's CMUCL/Motif server code). If the lisp-variant is
272 given but the motif-variant is not, the motif-variant is determined
273 from the lisp-variant.
274
275 The script will generate the target directory tree, link the relevant
276 Config files, and generate place-holder files for various files, in
277 order to ensure proper operation of the other build-scripts. It also
278 creates a sample setenv.lisp file in the target directory, which is
279 used by the build and load processes to set up the correct list of
280 *features* for your target lisp core.
281
282 IMPORTANT: You will normally NOT have to modify the sample setenv.lisp
283 file, if you are building from a binary that has the desired features.
284 In fact, the sample has all code commented out, If you want to add or
285 remove features, you need to include code that puts at least a minimal
286 set of features onto the list (use PUSHNEW and/or REMOVE). You can
287 use the current set of *features* of your lisp as a first guide. The
288 sample setenv.lisp includes a set of features that should work for the
289 intended configuration. Note also that some adding or removing some
290 features may require a cross-compile instead of a normal compile.
291
292 * src/tools/clean-target.sh [-l] target-directory [more dirs]
293
294 Cleans the given target directory, so that all created files will be
295 removed. This is useful to force recompilation. If the -l flag is
296 given, then the C runtime is also removed, including all the lisp
297 executable, any lisp cores, all object files, lisp.nm, internals.h,
298 and the config file.
299
300 * src/tools/build-world.sh target-directory [build-binary] [build-flags...]
301
302 Starts a complete world build for the given target, using the lisp
303 binary/core specified as a build host. The recompilation step will
304 only recompile changed files, or files for which the fasl files are
305 missing. It will also not recompile the C runtime code (the lisp
306 binary). If a (re)compilation of that code is needed, the genesis
307 step of the world build will inform you of that fact. In that case,
308 you'll have to use the rebuild-lisp.sh script, and then restart the
309 world build process with build-world.sh
310
311 * src/tools/rebuild-lisp.sh target-directory
312
313 This script will force a complete recompilation of the C runtime code
314 of CMU CL (aka the lisp executable). Doing this will necessitate
315 building a new kernel.core file, using build-world.sh.
316
317 * src/tools/load-world.sh target-directory version
318
319 This will finish the CMU CL rebuilding process, by loading the
320 remaining compiled files generated in the world build process into the
321 kernel.core file, that also resulted from that process, creating the
322 final lisp.core file.
323
324 You have to pass the version string as a second argument. The dumped
325 core will anounce itself using that string. Please don't use a string
326 consisting of an official release name only, (e.g. "18d"), since those
327 are reserved for official release builds. Including the build-date in
328 ISO8601 format is often a good idea, e.g. "18d+ 2002-05-06" for a
329 binary that is based on sources current on the 6th May, 2002, which is
330 post the 18d release.
331
332 * src/tools/build-utils.sh target-directory
333
334 This script will build auxiliary libraries packaged with CMU CL,
335 including CLX, CMUCL/Motif, the Motif debugger, inspector, and control
336 panel, and the Hemlock editor. It will use the lisp executable and
337 core of the given target.
338
339 * src/tools/make-dist.sh [-bg] [-G group] [-O owner] target-directory version arch os
340
341 This script creates both main and extra distribution tarballs from the
342 given target directory, using the make-main-dist.sh and
343 make-extra-dist.sh scripts. The result will be two tar files. One
344 contains the main distribution including the runtime and lisp.core
345 with PCL (CLOS); the second contains the extra libraries such as
346 Gray-streams, simple-streams, CLX, CLM, and Hemlock.
347
348 Some options that are available:
349
350 -b Use bzip2 compression
351 -g Use gzip compression
352 -G group Group to use
353 -O owner Owner to use
354
355 If you specify both -b and -g, you will get two sets of tarfiles. The
356 -G and -O options will attempt to set the owner and group of the files
357 when building the tarfiles. This way, when you extract the tarfiles,
358 the owner and group will be set as specified. You may need to be root
359 to do this because many Unix systems don't normally let you change the
360 owner and group of a file.
361
362 The remaining arguments used to create the name of the tarfiles. The
363 names will have the form:
364
365 cmucl-<version>-<arch>-<os>.tar.bz2
366 cmucl-<version>-<arch>-<os>.extras.tar.bz2
367
368 Of course, the "bz2" will be "gz" if you specified gzip compression
369 instead of bzip.
370
371 * /src/tools/make-main-dist.sh target-directory version arch os
372
373 This is script is not normally invoked by the user; make-dist will do
374 it appropriately.
375
376 This script creates a main distribution tarball (both in gzipped and
377 bzipped variants) from the given target directory. This will include
378 all the stuff that is normally included in official release tarballs
379 such as lisp.core and the PCL libraries, including Gray streams and
380 simple streams.
381
382 This is intended to be run from make-dist.sh.
383
384 * src/tools/make-extra-dist.sh target-directory version arch os
385
386 This is script is not normally invoked by the user; make-dist will do
387 it appropriately.
388
389 This script creates an extra distribution tarball (both in gzipped and
390 bzipped variants) from the given target directory. This will include
391 all the stuff that is normally included in official extra release
392 tarballs, i.e. the auxiliary libraries such as CLX, CLM, and Hemlock.
393
394 This is intended to be run from make-dist.sh.
395
396
397 * cross-build-world.sh target-directory cross-directory cross-script
398 [build-binary] [build-flags...]
399
400 This is a script that can be used instead of build-world.sh for
401 cross-compiling CMUCL. In addition to the arguments of build-world.sh
402 it takes two further required arguments: The name of a directory that
403 will contain the cross-compiler backend (the directory is created if
404 it doesn't exist, and must not be the same as the target-directory),
405 and the name of a Lisp cross-compilation script, which is responsible
406 for setting up, compiling, and loading the cross-compiler backend.
407 The latter argument is needed because each host/target combination of
408 platform's needs slightly different code to produce a working
409 cross-compiler.
410
411 We include a number of working examples of cross-compiler scripts in
412 the cross-scripts directory. You'll have to edit the features section
413 of the given scripts, to specify the features that should be removed
414 from the current set of features in the host lisp, and those that
415 should be added, so that the backend features are correct for the
416 intended target.
417
418 You can look at Eric Marsden's collection of build scripts for the
419 basis of more cross-compiler scripts.
420
421 Step-by-Step Example of recompiling CMUCL for OpenBSD
422 -----------------------------------------------------
423
424 Set up everything as described in the setup section above. Then
425 execute:
426
427 # Create a new target directory structure/config for OpenBSD:
428 src/tools/create-target.sh openbsd OpenBSD_gencgc OpenBSD
429
430 # edit openbsd/setenv.lisp to contain what we want:
431 cat <<EOF > openbsd/setenv.lisp
432 ;;; Put code to massage *features* list here...
433
434 (in-package :user)
435
436 (pushnew :openbsd *features*)
437 (pushnew :bsd *features*)
438 (pushnew :i486 *features*)
439 (pushnew :mp *features*)
440 (pushnew :hash-new *features*)
441 (pushnew :random-mt19937 *features*)
442 (pushnew :conservative-float-type *features*)
443 (pushnew :gencgc *features*)
444
445 ;;; Version tags
446
447 (pushnew :cmu18d *features*)
448 (pushnew :cmu18 *features*)
449 (setf *features* (remove :cmu17 *features*))
450 (setf *features* (remove :cmu18c *features*))
451 EOF
452
453 # Recompile the lisp world, and dump a new kernel.core:
454 src/tools/build-world.sh openbsd lisp # Or whatever you need to invoke your
455 # current lisp binary+core
456
457 # If build-world tells you (as it will the first time) that:
458 # "The C header file has changed. Be sure to re-compile the startup
459 # code."
460 # You 'll need to start rebuild-lisp.sh to do that, and then reinvoke
461 # build-world.sh:
462
463 # Recompile lisp binary itself:
464 src/tools/rebuild-lisp.sh openbsd
465
466 # Restart build-world.sh now:
467 src/tools/build-world.sh openbsd lisp
468
469 # Now we populate the kernel.core with further compiled files,
470 # and dump the final lisp.core file:
471
472 src/tools/load-world.sh openbsd "18d+ 2002-05-06"
473
474 # The second argument above is the version number that the built
475 # core will announce. Please always put the build-date and some
476 # other information in there, to make it possible to differentiate
477 # those builds from official builds, which only contain the release.
478
479 Now you should have a new lisp.core, which you can start with
480
481 ./openbsd/lisp/lisp -core ./openbsd/lisp/lisp.core -noinit -nositeinit
482
483 Compiling sources that contain disruptive changes
484 -------------------------------------------------
485
486 The above instructions should always work as-is for recompiling CMU CL
487 using matching binaries and source files. They also work quite often
488 when recompiling newer sources. However, every so often, some change
489 to the CMU CL sources necessitates some form of bootstrapping, so that
490 binaries built from earlier sources can compile the sources containing
491 that change. There are two forms of boostrapping that can be
492 required:
493
494 a) Bootfiles
495
496 The maintainers try to make bootfiles available, that allow going
497 from an old release to the next release. These are located in the
498 src/bootfiles/<old-release>/ directory of the CMU CL sources.
499
500 I.e. if you have binaries that match release 18d, then you'll need
501 to use all the bootfiles in src/bootfiles/18d/ in order to go to
502 the next release (or current sources, if no release has been made
503 yet). If you already used some of the bootstrap files to compile
504 your current lisp, you obviously don't need to use those to get to
505 later versions.
506
507 You can use the bootfiles by concatenating them into a file called
508 bootstrap.lisp in the target directory (i.e. target:bootstrap.lisp)
509 in the order they are numbered. Be sure to remove the bootstrap
510 file once it is no longer needed.
511
512 Alternatively, the bootstrap file can just "load" the individual
513 bootfiles as needed.
514
515 b) Cross-compiling
516
517 Under some circumstances, bootstrap code will not be sufficient,
518 and a cross-compilation is needed. In that case you will have to
519 use cross-build-world.sh, instead of build-world.sh. Please read
520 the instructions of that script for details of the more complex
521 procedure.
522
523 << This isn't really true anymore, and we should place a more
524 elaborate description of the cross-compiling process here >>
525
526 When cross-compiling, there are two sorts of bootscripts that can be
527 used: Those that want to be executed prior to compiling and loading
528 the cross-compiler, which should be placed in the file called
529 target:cross-bootstrap.lisp, and those that should happen after the
530 cross-compiler has been compiled and loaded, just prior to compiling
531 the target, which should be placed in target:bootstrap.lisp, just
532 like when doing a normal recompile.
533
534 Additionally, sometimes customized cross-compiler setup scripts
535 (to be used in place of e.g. cross-x86-x86.lisp) are required,
536 which are also placed in one of the bootfiles/*/* files. In those
537 cases follow the instructions provided in that file, possibly merging
538 the changed contents thereof with your normal cross-script.
539
540 Step-by-Step Example of Cross-Compiling
541 ---------------------------------------
542
543 This gives a step-by-step example of cross-compiling a sparc-v8 build
544 using a sparc-v9 build. (For some unknown reason, you can't just
545 remove the :sparc-v9 feature and add :sparc-v8.)
546
547 So, first get a recent sparc-v9 build. It's best to get a version
548 that is up-to-date with the sources. Otherwise, you may also need to
549 add a bootstrap file to get any bootfiles to make your lisp
550 up-to-date with the current sources.
551
552 1. Select a directory for the cross-compiler and compiled target:
553
554 Create a cross-compiler directory to hold the cross-compiler
555 and a target directory to hold the result:
556
557 src/tools/create-target.sh xcross
558 src/tools/create-target.sh xtarget
559
560 2. Adjust cross-compilation script
561
562 Copy the src/tools/cross-scripts/cross-sparc-sparc.lisp to
563 xtarget/cross.lisp. Edit it appropriately. In this case, it
564 should look something like:
565
566 (c::new-backend "SPARC"
567 ;; Features to add here
568 '(:sparc :sparc-v8
569 :complex-fp-vops
570 :linkage-table
571 :gencgc
572 :stack-checking
573 :relative-package-names
574 :conservative-float-type
575 :hash-new :random-mt19937
576 :cmu :cmu19 :cmu19a
577 )
578 ;; Features to remove from current *features* here
579 '(:sparc-v9 :sparc-v7 :x86 :x86-bootstrap :alpha :osf1 :mips
580 :propagate-fun-type :propagate-float-type :constrain-float-type
581 :openbsd :freebsd :glibc2 :linux :pentium
582 :long-float :new-random :small))
583
584 (setf *features* (remove :sparc-v9 *features*))
585 (pushnew :sparc-v8 *features*)
586
587 It's important to add frob *features* here as well as in the
588 new-backend. If you don't adjust *features*, they won't be
589 set appropriately in the result.
590
591 3. Build the cross compiler and target
592 Now compile the result:
593
594 src/tools/cross-build-world.sh xtarget xcross xtarget/cross.lisp [v9 binary]
595
596 4. Rebuild the lisp files:
597
598 When this finishes, you need to compile the C code:
599
600 src/tools/rebuild-lisp.sh xtarget
601
602 At this point, you may want to run cross-build-world.sh again
603 to generate a new kernel.core. It shouldn't build anything;
604 just loads everything and creates a kernel.core.
605
606 5. Build the world:
607
608 With the new kernel.core, we need to create a lisp.core:
609
610 src/tools/load-world.sh xtarget "new lisp"
611
612 Test the result with
613
614 xtarget/lisp/lisp -noinit
615
616 However, this lisp will be missing some functionality like PCL. You
617 probably now want to use the compiler to rebuild everything once
618 again. Just follow the directions for a normal build, and use
619 xtarget/lisp/lisp as your compiler. Be sure to use create-target.sh
620 to create a new directory where the result can go.
621
622 Cross-Platform Cross-Compile
623 ----------------------------
624
625 A cross-platform cross-compile is very similar to a normal
626 cross-compile, and the basic steps are the same. For the sake of
627 concreteness, assume we are on ppc/darwin and want to cross-compile
628 to x86/linux.
629
630 To simplify things, we assume that both platforms have access to the
631 same file system, via NFS or something else.
632
633 1. As above, we need to create directories for the cross-compiler and
634 compiled target. We assume we are on ppc/darwin. So, when running
635 create-target.sh we need to specify the target:
636
637 src/tools/create-target.sh x86-cross x86
638 src/tools/create-target.sh x86-target x86
639
640 2. Adjust the cross-compilation script. An example for ppc/darwin to
641 x86/linux is in src/tools/cross-scripts/cross-ppc-x86.lisp.
642
643 3. Build the cross compiler and target, as above, using the specified
644 cross-compile script:
645
646 src/tools/cross-build-world.sh x86-target x86-cross cross.lisp [ppc binary]
647
648 where cross.lisp is the cross-compile script from 2) above.
649
650 4. Everything has now been compiled for the x86/linux target. We need
651 to compile the C code for x86 and create a lisp.core from the
652 kernel.core. This is where it's useful to have both platforms be
653 able to access the same file system. If not, you will need to copy
654 all of the generated files from ppc/darwin to x86/linux. Basically
655 everything in xtarget needs to be copied.
656
657 Note carefully that you may have to edit lisp/internals.h and/or
658 lisp/internals.inc to have the correct features. This is a known
659 bug in the generation of these files during cross-compilation.
660
661 Compile the lisp code:
662
663 src/tools/rebuild-lisp.sh x86-target
664
665 5. Now run load-world.sh to create the desired lisp.core from lisp and
666 kernel.core. As above, PCL has not been compiled, so select
667 restart 3 (return nil from pclload) to create lisp.core
668
669 src/tools/load-world.sh x86-target "new x86"
670
671 At this point, you will have a shiny new lisp on the new platform.
672 Since it's missing PCL, you will need to do at least one normal build
673 to get PCL included. This is also a good check to see if everything
674 was compiled properly. A full set of builds via build.sh might be
675 good at this point too.
676
677 Some of the details for each command may have changed; You can get
678 help for each command by using the -h argument.
679
680 In particular steps 3, 4, and 5 can be combined into one by using the
681 -c, -r, and -l options for cross-build-world.sh. The -c option cleans
682 out the targe and cross directories; -r does step 4; and -l does step
683 5.

  ViewVC Help
Powered by ViewVC 1.1.5