1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
|
<html>
<head>
<title>crosstool-howto</title>
</head>
<body>
<h1>crosstool-howto</h1>
Crosstool is a set of scripts to build and test several versions of gcc and glibc for
most architectures supported by glibc.
It will even download and patch the original tarballs for you.
The resulting script and associated patches, and the latest version of this doc,
are available at <a href="http://kegel.com/crosstool/">kegel.com/crosstool</a>.
<p>
Crosstool was originally developed for embedded system developers, but is also useful for mainstream developers who
simply want their compiles to go fast or who need to build programs that
run on older versions of Linux (e.g. Red Hat 6.2), but don't want to develop
on those ancient systems.
<p>
It includes minimal patches for gcc and glibc needed to build a few combinations of
(alpha, arm, i686, ia64, mips, powerpc, powerpc64, sh4, sparc, sparc64, s390, x86_64) x
(gcc-2.95.3 ... gcc-4.0.0) x
(glibc-2.1.3 ... glibc-2.3.5).
<p>
It also supports building toolchains that target Cygwin; see demo-cygwin.sh.
<p>
Crosstool is a portable shell script. You can use it to build linux-targeted compilers that run
on Linux, Mac OS X, Solaris, and Cygwin. It includes support for creating hetrogenous build
clusters; it lets you use virtually every computer in the building, regardless of operating
system or CPU type, to speed up your Linux compiles.
<h2>Contents</h2>
<ul>
<li><a href="#quick">Quick Start</a></li>
<li><a href="#rpm">Building RPMs</a></li>
<li><a href="#static">Static Builds</a></li>
<li><a href="#distcc">Faster builds with distcc</a></li>
<li><a href="#hetrogenous">Hetrogenous distcc clusters</a></li>
<li><a href="#canadian">Canadian Cross Builds</a></li>
<li><a href="#scripts">Scripts</a></li>
<li><a href="#data">Data Files</a></li>
<li><a href="#notes">Notes</a></li>
<li><a href="#testing">Testing</a></li>
<li><a href="#all">all.sh</a></li>
<li><a href="#buildnotes">Build Platform Notes</a>
<ul>
<li><a href="#linux">Linux</a></li>
<li><a href="#netbsd">NetBSD</a></li>
<li><a href="#mac">Mac OS X</a></li>
<li><a href="#cygwin">Cygwin</a></li>
<li><a href="#solaris">Solaris</a></li>
</ul></li>
<li><a href="#targetnotes">Target Platform Notes</a>
<ul>
<li><a href="#mips">MIPS</a></li>
<li><a href="#sh3">SH3</a></li>
<li><a href="#sh4">SH4</a></li>
<li><a href="#cris">CRIS</a></li>
<li><a href="#arm-xscale">ARM-Xscale</a></li>
<li><a href="#arm-iwmmxt">ARM-iwmmxt</a></li>
</ul></li>
<li><a href="#troubleshooting">Troubleshooting</a></li>
<li><a href="#issues">Current Issues</a></li>
<li><a href="#buildlogs">Build Status</a></li>
<li><a href="#uclibc">uClibc</a></li>
<li><a href="#contrib">Contributed Patches</a></li>
<li><a href="#links">Links</a></li>
</ul>
<h2><a name="quick">Quick Start</a></h2>
Download and unpack. For instance:
<pre>
wget http://kegel.com/crosstool/crosstool-0.42.tar.gz
tar -xzvf crosstool-0.42.tar.gz
cd crosstool-0.42
</pre>
Then look at the demo scripts; there's one for each supported CPU type.
For instance, demo-i686.sh is an example of how to build a toolchain that targets
the i686 processor. It sets three important variables:
<pre>
TARBALLS_DIR=$HOME/downloads # where it will save source tarballs
RESULT_TOP=/opt/crosstool # where it will install the tools
GCC_LANGUAGES="c,c++,java,f77" # which languages it will make compilers for
</pre>
It then builds gcc-3.4.0 and glibc-2.3.2 for i686 with the line
<pre>
eval `cat i686.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --notest
</pre>
Edit the script if you want to change any of these settings or versions.
Then (as root) create the directory /opt/crosstool and make it writable by you, and
finally (as yourself) run the demo script, e.g.
<pre>
sudo mkdir /opt/crosstool
sudo chown $USER /opt/crosstool
sh demo-i686.sh
</pre>
When it finishes, you can run the new compiler as /opt/crosstool/gcc-3.4.0-glibc-2.3.2/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-gcc.
(You might want to put /opt/crosstool/gcc-3.4.0-glibc-2.3.2/i686-unknown-linux-gnu/bin on your PATH; then you
can run the compiler as i686-unknown-linux-gnu-gcc.)
<h2><a name="static">Static Builds</a></h2>
If for some reason you want the resulting toolchain binaries to
be statically linked, set the following environment variables before
running crosstool.sh (or all.sh):
<pre>
BINUTILS_EXTRA_CONFIG="LDFLAGS=-all-static"
GCC_EXTRA_CONFIG="LDFLAGS=-static"
</pre>
<h2><a name=rpm>Building RPMs</a></h2>
Building RPMs of the compiler used to be done by the same shell script, all.sh, with the --buildrpm option,
but that was not enough to satisfy real Linux distributions, which require true .src.rpm's.
So now the procedure to build an RPM is to first build the .src.rpm, then build the .rpm from
that, using rpmbuild in the traditional way.
<p>
A script demonstrating how to build .src.rpm's is buildsrpms.sh.
A script demonstrating how to build both .src.rpm's and .rpm's is buildrpms.sh.
Both of these are only examples; I use them myself to build a specific set of toolchains.
<p>
Each .src.rpm generated by buildsrpms.sh builds toolchains
for all supported CPUs, where 'supported' means 'the CPU is listed in the buildlogs directory as
having successfully built a working toolchain'.
This greatly cuts down on the number of .src.rpm's needed.
To build for just e.g. i686, run rpmbuild with options "--without all --with i686".
<h2><a name="distcc">Faster builds with distcc</a></h2>
You can use <a href="http://distcc.samba.org">distcc</a> to distribute compilation across multiple computers for faster compiles.
The distcc that comes with your version of Linux will work fine for most cases.
However, it may be more convenient to instead use the script 'mkdistcc.sh'
included with crosstool to install a crosstool-specific distcc
(partly because that's what the mkdistcclinks.sh script assumes,
and partly because it includes a patch that improves support for large hetrogenous clusters; see <a href="hetrogenous">below</a>).
<p>
To install distcc/distccd from source, run
<pre>
RESULT_TOP=/opt/crosstool \
TARBALLS_DIR=$HOME/downloads \
sh mkdistcc.sh
cd /opt/crosstool
sh common/bin/mkdistcclinks.sh
</pre>
To set up distccd as a service, run
<pre>
sudo sh /opt/crosstool/common/bin/install-distccd.sh
</pre>
<p>
Regardless of how you installed crosstool-distcc, you then need to
edit /opt/crosstool/common/etc/hosts and append the hostnames of all the computers running your distccd.
<p>
You can then run the distributed compiler as /opt/crosstool/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/<b>distributed</b>/bin/i686-unknown-linux-gnu-gcc.
(You might want to put /opt/crosstool/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/<b>distributed</b>/bin on your PATH; then you
can run the distributed compiler as i686-unknown-linux-gnu-gcc.)
<p>
To get any speed benefit, you'll need
to run several compiles in parallel. See e.g. <a
href="http://www.gnu.org/software/make/manual/html_chapter/make_5.html#SEC55">make's
-j option</a>. Also note that only simple <b>compiling with the -c option</b>,
not linking, is sped up, and that only C and C++
compiles are distributed (fortran and java compiles are not distributed,
sorry).
<p>
Getting the best performance out of distcc is a fine art.
See e.g. Benjamin Meyer's page
"<a href="http://www.csh.rit.edu/slashdot/distcc.html">Distcc optimizations and how to compile kdelibs from scratch in six minutes</a>".
<p>
You can monitor your distcc jobs by running
<pre>
/opt/crosstool/common/bin/distccmon-test 5
</pre>
This will display a description of your active remote jobs once every five seconds.
<h2><a name="hetrogenous">Hetrogenous distcc clusters</a></h2>
Here's a scenario sometimes useful at large universities or companies, where one often has a central file server which all clients access.
Crosstool is built for multiple versions of gcc and glibc, once for kind of workstation in the cluster,
and installed in e.g. /shared/crosstool/`config.guess`.
Compilers are invoked via absolute paths so toolchains with different versions of glibc can be distinguished.
The absolute path is built using config.guess so, regardless of which
kind of workstation the developer is on, he or she can invoke a compiler that can run on their workstation.
<p>
For example, when building a C program for modern x86 linux, developers set
<pre>
CC=/shared/crosstool/`config.guess`/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/distributed/bin/i686-unknown-linux-gnu-gcc
</pre>
And when building a C program for old Red Hat Linux 6.2 x86, developers might set
<pre>
CC=/shared/crosstool/`config.guess`/gcc-3.3.3-glibc-2.1.3/i686-unknown-linux-gnu/distributed/bin/i686-unknown-linux-gnu-gcc
</pre>
<p>
A tricky part of this scenario is that the distcc server needs to be able to handle absolute paths
for *other* architectures, possibly installed at a different location.
The patch patches/distcc-2.14/distcc-stringmap.patch, applied by mkdistcc.sh,
adds a feature to the distccd server to read a $prefix/etc/distcc/apps file containing absolute paths
to all known compilers, and to ignore all but the last N path components when locating the compiler to satisfy received compile requests.
The distccd startup scripts created by crosstool's install-distccd.sh turn on that feature.
<p>
gcc-3.4.0's precompiled headers and profile-driven optimization features
require lockstep synchronization, so they probably work only if the client and
the server are the same CPU type and operating system. (And using pch with distcc may require
apple's -fpch-preprocess patch; see http://gcc.gnu.org/ml/gcc/2003-03/msg00369.html)
<h2><a name="canadian">Canadian Cross Builds</a></h2>
Those long, strange names of the form "i686-unknown-linux-gnu" are called
<a href="http://sources.redhat.com/autobook/autobook/autobook_17.html">GNU
configuration names</a>. The GNU build and test scripts use these
extensively. When you run the demo-$CPU.sh script, it sources
the $CPU.dat file, which sets a variable TARGET containing the GNU configuration
name for the target CPU. For instance, i686.dat contains the line
<pre>
TARGET=i686-unknown-linux-gnu
</pre>
In the general case, there can be three machine types: the <i>build</i> machine which builds the compilers,
the <i>host</i> machine where the compilers will run, and the <i>target</i> machine
for which the compilers will generate code.
<p>
Building compilers that will run on some <b>other</b> linux system
is called a Canadian Cross. It's useful if, say, you're putting together
a hetrogenous build cluster consisting of 32 bit and 64 bit workstations,
and you want to run natively compiled compilers on each.
<p>
To do a Canadian Cross build with crosstool, you have to run it <b>three times</b>:
<ol>
<li>once to build a toolchain that runs on the build system and generates code for the host system
<li>once to build a toolchain that runs on the build system and generates code for the target system
<li>once to build a toolchain that runs on the host system and generates code for the target system
</ol>
The last two runs are identical except that on the last run, you have to set a few environment variables:
<ul>
<li>GCC_HOST should be the GNU configuration name (e.g. powerpc-750-linux-gnu) of the <i>host</i> machine
<li>PATH must be set to include the bin directory of the host and target compilers that can run on the build machine
<li>CC, AR, and RANLIB have to be set to a compiler that generates code that runs on the host,
and versions of ar and ranlib that
can handle archives of code for the host.
</ul>
demo-canadian.sh (when I finish it) will demonstrate how to get this working.
<p>
If you want the use resulting toolchain as a native toolchain, i.e.
if you want it to search /lib and /usr/lib, you'll probably need to edit
its specs file to set the cross_compiler parameter to 0;
see <a href="http://sources.redhat.com/ml/crossgcc/2004-06/msg00161.html">this thread in the crossgcc mailing list</a>.
<h2><a name=scripts>Scripts</a></h2>
<ul>
<li><tt>crosstool.sh</tt>: Compiles gcc and glibc. This is the most important file, and it can be used by itself,
without any other files from the tarball, if you are so inclined.
<li><tt>getandpatch.sh</tt>: Download, unpack, and patch the binutils, linux, gcc, and glibc source tarballs.
<li><tt>crosstest.sh</tt>: Run the gcc and glibc regression tests remotely.
<li><tt>ptx.sh</tt>: Build userland apps (e.g. /bin/sh) using <a href="http://ptxdist.sf.net">ptxdist</a>.
<li><tt>testhello.sh</tt>: Verifies trivial programs can be built with the new compiler
<li><tt>all.sh</tt>: Invoke all the above scripts. Supposedly more convenient that running them individually. (<a href="#all">See below.</a>)
<li><tt>mkdistcc.sh</tt>: A script to download, build, and patch distcc.
<li><tt>mkdistcclinks.sh</tt>: A script to create masquerade directories for each installed compiler to make using distcc easier.
<li><tt>demo-CPU.sh</tt>: One demo script for each CPU type that sets environment variables for that CPU, then runs all.sh and mkdistcc.sh.
<li><tt>demo.sh</tt>: Big demo script that runs all the little demo-CPU.sh scripts.
<li><tt>clean.sh</tt>: remove junk files; used by maintainer before creating tarballs
<li><tt>mkjail.sh</tt>: create the files needed for a chroot jail (useful when doing regression testing of glibc)
<li><tt>testjail.sh</tt>: test a remote chroot jail
</ul>
<h2><a name=data>Data Files</a></h2>
<ul>
<li><tt>CPU.dat</tt>: One file for each CPU type; sets GNU target name
<li><tt>gcc-VERSION-glibc-VERSION.dat</tt>: One file for each supported combination of gcc and glibc; sets binutils, gcc, and glibc versions and options
<li><tt>patches/PROGRAM/*.patch</tt>: the patches I needed for each version of each program.
The patches for each tool are stored in a subdirectory of <a href="../patches/">patches/</a>
named after the tool (e.g. <a href="../patches/gcc-3.3/">patches/gcc-3.3</a>).
Each patch starts with comments about what it's for, and has links to any associated discussion.
This is a small but hopefully high quality and maintainable patch repository; newer versions of ptxdist use a mirror of this repository.
<li><tt>summaries/*</tt>: example outputs from old crosstest.sh runs
</ul>
<h2><a name=notes>Notes</a></h2>
If you want to build gcc-3.3 or later, you'll need a recent gcc (3.2 or later)
on your workstation to build it with.
<p>
The scripts are fairly generic.
You may need to tweak the parameters of the script to match your exact CPU type,
or add a few patches needed to the patches/* directories, and run the build script again,
if your tests indicate that programs built with the new compiler have problems.
<p>
In particular, if your CPU lacks an FPU, you might need to tell glibc that by setting
before running all.sh. For example, see powerpc-405.dat, which sets
<pre>
GLIBC_EXTRA_CONFIG="--without-fp"
</pre>
<p>
Once you trust the toolchain can build and run simple statically linked 'hello, world' programs
(see e.g. testhello.sh), test it with real applications.
<p>
If you use these scripts to build a toolchain, please send a note to the
<a href="http://sources.redhat.com/ml/crossgcc/">crossgcc mailing list</a>
indicating which platform you used it on, and
how well it worked for you. Please be sure to mention which release of the crosstool
scripts you used.
<p>
If you add support for a new CPU type, please send your changes to the crossgcc mailing
list so they can be incorporated in a future release.
<h2><a name=testing>Testing</a></h2>
If you're targeting i686-linux, and are using a released version of gcc
and glibc, you probably don't need to worry about testing the toolchain.
<p>
But if you're using a new or uncommon CPU type, or an unreleased version
of gcc or glibc, and want some assurance that you have built a working
compiler and C library, you should run the gcc and glibc test suites.
See <a href="crosstest-howto.html">crosstest-howto.html</a>.
<h2><a name=all>all.sh</a></h2>
all.sh invokes the four scripts that download, build, and test the toolchain.
It takes four options:
<ul>
<li>--nounpack, which means 'don't run getandbuild.sh'. This is useful for quick reruns or when just testing.
<li>--nobuild, which means 'don't run crosstool.sh'. This is useful for when you just want to run regression tests.
<li>--builduserland, which means 'run ptx.sh'. This is useful for when you need to build busybox for some reason,
e.g. if you want to run the regression tests, but the target's normal shell can't run against the new shared C libraries.
<li>--notest, which means 'don't run crosstest.sh'. This is useful for when you don't have a target to test on,
or don't want to spend the time to test. See <a href="crosstest-howto.html">crosstest-howto.html</a> for information about running the test suite.
</ul>
<h2><a name="buildnotes">Build Platform Notes</a></h2>
<h3><a name="linux">Linux</a></h3>
Crosstool was developed on Linux, so most of the rough edges have been polished off.
However, if running crosstool.sh on Linux fails with an error like
<pre>
"soinit.c:25: internal compiler error: in named_section_flags, at varasm.c:..."
</pre>
then you may be running into gcc bug <a href="http://gcc.gnu.org/PR9552">9552</a>.
One workaround is to delete the file gcc-pr-9552-workaround.patch
from crosstool/patches/glibc-2.3.2, and rerun. Another is to switch
to a different version of binutils (2.14 seems to be the dividing line).
<h3><a name=netbsd>NetBSD</a></h3>
You'll need to install GNU Diffutils or GNU Patch, since BSD's patch utility
doesn't accept the --fuzz parameter.
<h3><a name=mac>Mac OS X</a></h3>
To build gcc and glibc on Mac OS X, you'll need to install a few gnu utilities:
<ul>
<li>gnu wget
<li>gnu awk
<li>gnu sed
<li>gnu install (part of gnu coreutils)
</ul>
such that they are used instead of the native versions. (This may involve
setting PATH and/or making symbolic links.)
<p>
The way I installed them was using <a href="http://fink.sourceforge.net/">fink</a>,
but <a href="http://darwinports.opendarwin.org/">DarwinPorts</a>
or installing from tarballs would probably do as well.
<p>
One recurring problem is that various Gnu configure scripts assume that
'as' and 'ld' are the Gnu versions, run them with -v to get the
version number, and compare it with some gnu version.
That doesn't work well on the Mac. You can either hack the
configure scripts to not do that, or write wrapper scripts for
as and ld. For instance, here's a wrapper script for as that
blatantly lies about what version it is, just to make crosstool happy:
<pre>
test "$1" = -v && echo GNU assembler 2.13 || /usr/bin/as "$@"
</pre>
Nikolaus Schaller tied all the above into a tidy script; see his
<a href="http://sourceware.org/ml/crossgcc/2006-02/msg00272/build.sh">build.sh</a>
which both downloads the needed tools and creates the wrappers for as and ld.
<p>
On some (older?) versions of Mac OS X, you'll need to raise the stack size with the command
<pre>ulimit -s 8192</pre>
else make may segfault.
<p>
When using 2.6 kernel headers on systems (like Mac OS X) where gcc doesn't support the
-shared flag, you may see the error
<pre>
gcc: unrecognized option `-shared'
ld: Undefined symbols:
_main
make[1]: *** [scripts/kconfig/libkconfig.so] Error 1
make: *** [oldconfig] Error 2
</pre>
This is a well-known issue (see e.g.
<a href="http://www.uwsg.iu.edu/hypermail/linux/kernel/0211.0/2145.html">Peter Samuelson's post of 7 Nov 2002</a>
Bertrand Marquis a patch that might help
<a href="http://sources.redhat.com/ml/crossgcc/2004-06/msg00282.html">on 29 June 2004</a>.
It would be nice if someone figured out a patch
that could go into the mainline kernel sources to deal with this issue.
<p>
Another problem building Linux on Mac OS X is described, together with a Mac OS X specific workaround, by
<a href="http://sources.redhat.com/ml/crossgcc/2004-05/msg00182.html">Martin Schaffner's post of 22 May 2004</a>.
<h3><a name=cygwin>Cygwin</a></h3>
Crosstool, and probably gcc and glibc's configure scripts, assume that
directory names <b>do not</b> contain any spaces.
This is often violated on Windows. Please take care to not use
directory names with spaces in them when running crosstool.
It might work, but if it doesn't, you've been warned.
(Same goes for Mac OS X.)
<p>
crosstool creates some really deeply nested directories while building,
so filenames are quite long. This has two consequences:
<p>
First, on some versions of Windows, filenames (including directory) can't
be longer than 240 chars. To avoid exceeding this limit, don't run crosstool in
a directory with a long name.
<p>
Second, the maximum length of commandlines is extremely short.
Since crosstool uses commandlines that include multiple filenames,
they can exceed the limit very quickly.
You can avoid this problem by using the "mount" command's options.
e.g. mount /bin and /usr/bin with -X or "-o cygexec" (see <a href="http://www.cygwin.com/faq/faq-nochunks.html#faq.programming.make-execvp">the cygwin faq</a>,
and/or mount the crosstool directory with "-o managed" (see <a href="http://www.cygwin.com/cygwin-ug-net/using-utils.html#mount">the cygwin doc for "mount"</a>).
<p>
Also, this isn't really a crosstool problem, but configuring linux-2.6 on cygwin may fail with the error
<pre>
$ make menuconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/split-include
HOSTCC scripts/basic/docproc
HOSTLD scripts/kconfig/mconf
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
</pre>
A possible fix described e.g.
<a href="http://sources.redhat.com/ml/crossgcc/2004-06/msg00282.html">by Bertrand Marquis' post of 29 June 2004</a>
is to patch linux-2.6/scripts/kconfig/Makefile to just use libkconfig.o rather than first making a .so.
<p>
<a href="http://www.cygwin.com/ml/cygwin/2004-03/msg01006.html">Cygwin-1.5.9-1 had a bug that prevents it from building glibc</a>.
You can work around this by updating to Cygwin-1.5.10-2.
<h3><a name=solaris>Solaris Build Considerations</a></h3>
Crosstool ought to build on Solaris as long as it has been updated with
the appropriate set of GNU tools, but this has not been tested.
<p>
binutils-2.15 may require <a href="http://sources.redhat.com/ml/binutils/2004-06/msg00114.html">this patch</a>
to work on Solaris, else it is said to segfault when building the Linux kernel.
<p>
glibc documents which GNU tools it requires in <a href="http://www.gnu.org/software/libc/manual/html_node/Tools-for-Compilation.html">its INSTALL file</a>.
The list is roughly: make 3.79, GCC 3.2, binutils 2.13, texinfo 3.12f, awk 3.0, sed 3.02, or newer.
gcc documents a few other requirements in <a href="http://gcc.gnu.org/install/specific.html#*-*-solaris2*">gcc.gnu.org/install/specific.html</a>, which
says that gcc won't build at all with the default solaris shell, and
you're supposed to work around it like this:
<pre>
% CONFIG_SHELL=/bin/ksh
% export CONFIG_SHELL
</pre>
before running crosstool.
<p>
That page also advises that you may need to install some Solaris patches,
and install gcc-3.2.3 or newer before trying to build newer versions of gcc.
<h2><a name="targetnotes">Target Platform Notes</a></h2>
<h3><a name=mips>MIPS</a></h3>
<p>Little-endian MIPS
<p>
To create a toolchain for the Linksys wrt54g, select glibc-2.2.3.
See <a href="http://seattlewireless.net/index.cgi/LinksysWrt54g">LinksysWrt54g</a>
<a href="http://www.batbox.org/wrt54g-linux.html">wrt54g-linux.html</a>
<p>
Note: recent wrt54g firmware uses uclibc, which behaves like a subsetted glibc.
There are patches to build uclibc toolchains in the contrib directory,
but they're not integrated yet. However, you can still use a glibc
toolchain; you'll either have to
<ul>
<li> not call the missing functions,</li>
<li> use a stub library like
<a href="http://www.xse.com/leres/tivo/downloads/libtivohack/">libtivohack</a></li>
<li> link your programs statically if you want them to run on the
wrt54g.</li>
</ul>
<h3><a name=sh3>SH3</a></h3>
<p>
SH3 support is untested... it is said to build, and "hello, world" works,
but that's all I've heard.
<p>FIXME: The SH3 is supposedly the same as an SH4
but without the floating point unit, so maybe glibc has to be built
--without-fp. See powerpc-405.dat and
<a href="http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html#Configuring%20and%20compiling">Configuring and compiling GNU Libc</a>
<h3><a name=sh4>SH4</a></h3>
<p>
Note:
<ul>
<li>binutils < 2.13 doesn't know about SH4, so don't try building
gcc-2.95.</li>
<li>gcc-3.2.3 has ICE compiling glibc for SH4 (<a href="http://gcc.gnu.org/PR6954">PR6954</a>), so
don't try building gcc-3.2.3.</li>
</ul>
<h3><a name=cris>CRIS</a></h3>
<p>
CRIS doesn't build with glibc-2.3.2;
fails with "errno-loc.c:39: error: `pthread_descr' undeclared" in glibc build.
The cris glibc maintainer is aware of the problem and hopes to fix this later
in 2004, but we don't know if this has been done.
<p>
We removed cris support, demo-cris.sh, from crosstool. If you need it, you may find it in the
previous version of crosstool.
<h3><a name=arm-xscale>ARM-Xscale</a></h3>
<p>
gcc-3.3 doesn't support this, need gcc-3.4 or later.
<h3><a name=arm-iwmmxt>ARM-iwmmxt</a></h3>
<p>
gcc-3.3 doesn't support this, need gcc-3.4 or later.
<h2><a name="troubleshooting">Troubleshooting</a></h2>
<h3>Download Problems</h3>
all.sh calls getandpatch.sh, which looks in the directory specified by
TARBALLS_DIR for source tarballs, and downloads them to there if not found.
<p>
If the download hangs, and you need to use a proxy,
try telling wget about your proxy before running all.sh by doing
<pre>
$ export http_proxy=<proxy_host>:<port>
</pre>
If the download still hangs, download the tarball that's causing the hang manually to
the directory specified by TARBALLS_DIR.
<h2><a name=issues>Current Issues</a></h2>
<ul>
<li>all.sh's --builduserland seems to be broken at the moment.
<li>NPTL is not yet supported.
<li>These scripts, unlike Bill Gatliff's original crossgcc scripts,
don't support bare metal newlib targets. They should, but I needed to
focus on targeting Linux first. See contrib/newlib for a user-contributed fix.
<li>These scripts don't support uClibc yet, but <a href="#uclibc">see below</a>.
<li>The hppa target is not yet supported.
<li>glibc-2.3.2 doesn't build for cris; <a href="http://sources.redhat.com/ml/libc-alpha/2003-01/msg00008.html">looks
like the maintainer needs to create a sysdep-cancel.h for cris</a>.
I no longer try cris, since it seems to be unmaintained.
</ul>
See the <a href="../ChangeLog">ChangeLog</a> for more issues.
<h2><a name=buildlogs>Build Status</a></h2>
The script regtest-run.sh tries to build a number of combinations of gcc, glibc, and CPU,
and saves the last hundred or so lines of the build log in the file <a href="../buildlogs/">buildlogs</a>$cpu-$gcc-$glibc.log.txt,
along with a summary of the build in the file <a href="../buildlogs/">buildlogs</a>$cpu-$gcc-$glibc.dat.txt.
The script regtest-report.sh creates the file <a href="../buildlogs/index.html">buildlogs/$version/index.html</a> summarizing the results.
Note: this reflects whether the toolchains could be <i>built</i>, not whether they <i>work</i>!
Also note: running regtest-run.sh takes a LOT of cpu power, so
it uses ssh to spawn build jobs on multiple machines. Read the script carefully before running it.
<h2><a name=contrib>Contributed Patches</a></h2>
A few users of the crosstool scripts have submitted patches. I'm
saving these in the 'contrib' directory until I have time to test them.
<ul>
<li> testsetup - my scripts which are handy when running test suite remotely
<li> newlib, newlib2 - scripts to build newlib toolchains
<li> crosstool-uclibc-0.28-rc5.patch to build uclibc toolchains (see <a href="#uclibc">below</a>)
<li> contrib/xtool-ro.patch lets you run with sources in a read-only directory.
</ul>
<h2><a name=uclibc>uClibc</a></h2>
The script contrib/demo-uclibc.sh demonstrates how to patch an older version
of crosstool to support uclibc. This script, with editing,
can be used to build ARM7, PPC405, and maybe MIPS uclibc toolchains.
A future version of crosstool will merge the patch.
<h2><a name=links>Links</a></h2>
Patch repositories (handy if you are looking for a fix to a specific problem):
<ul>
<li><a href="http://ftp.jg555.com/patches/raq2/">Jim Gifford's MIPS / Raq2 patches</a>
<li><a href="http://www.andric.com/cross/patches">Dmitry Andric's ARM / vfp patches</a>
<li><a href="http://cvs.debian.org/glibc-package/debian/patches/?cvsroot=glibc">Debian's glibc patch repository</a>
<li><a href="http://www.pengutronix.de/software/ptxdist/patches-0.5.2/">PTXdist-0.5.2's patch repository</a>
<li><a href="http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/gcc/">Mandrake's gcc patch archive</a>
<li><a href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-devel/gcc/">gentoo's gcc build scripts</a>
<li><a href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-libs/glibc/">gentoo's glibc build scripts</a>
</ul>
There are many good general references for people building crosscompilers. Here is a somewhat outdated set:
<ul>
<li>Bill Gatliff's <a href="http://crossgcc.billgatliff.com/build-crossgcc.sh">crossgcc build script</a>
<li>Bill's <a href="http://billgatliff.com/twiki/bin/view/Crossgcc/ToolSetup">Crossgcc Wiki</a>
<li>Karim Yaghmour's book <a href="http://www.oreilly.com/catalog/belinuxsys/">Building Embedded Linux Systems</a>
<li>Karim Yaghmour's web site <a href="http://www.embeddedtux.org/">embeddedtux.org</a> and his
<a href="http://www.embeddedtux.org/gnu-tools.html">matrix of known working toolchain combinations</a>
<li><a href="http://www.embeddedlinuxinterfacing.com/sourcecode.shtml">Scripts from "Embedded Linux: Hardware, Software and Interfacing"</a>, by Dr. Craig Hollabaugh
<li>the <a href="http://sources.redhat.com/ml/crossgcc/">crossgcc mailing list</a>
<li><a href="http://buildroot.uclibc.org/">buildroot</a> - a cool build-from-scratch embedded distro by Erik Andersen.
<li><a href="http://www.pengutronix.de/software/ptxdist_en.html">PTXdist</a> - Another cool crossbuild-from-scratch embedded distro by Pengutronix/Robert Schwebel; uses a gui config menu
<li><a href="http://lug-owl.de/~jbglaw/linux-ports/#EasilyBuildableCrossToolchains">Proposal: Merging all Outstanding Linux Ports to Linus</a>, by Jan-Benedict Glaw
<li><a href="http://sed.inf.u-szeged.hu/gcc-arm/">GCC ARM pages at the University of Szeged</a> - very high quality resource;
impressive <a href="http://sed.inf.u-szeged.hu/gcc-arm/gnats.php">"ARM related GCC Bugzilla Problem Reports"</a>
and <a href="http://sed.inf.u-szeged.hu/gcc-arm/prs.php">"Results, Problem Reports and Patches"</a> pages.
<li><a href="ftp://ftp.linuxppc64.org/pub/people/janis/">Janis Johnson's powerpc64 biarch build script</a> - based on crosstool,
but supports biarch for powerppc32/64!
<li><a href="http://www.arm.linux.org.uk/developer/">ARM Linux Developer</a> pages - kernel stuff mostly
<li><a href="http://www.ltc.com/~brad/mips/mips-cross-toolchain.html">Building a Modern MIPS Cross-Toolchain for Linux</a>, by
Bradley D. LaRonde
<li><a href="http://www.develer.com/uclinux/uclinux-elf-tools.html">GCC 3.3 toolchain for uClinux ColdFire platforms</a> by Bernardo Innocenti
<li><a href="ftp://ftp.fairwayacademy.org/pub/armlinux/toolchain/">Jeff Sutherland's gcc-3.3 toolchain for xscale</a>
<li><a href="http://sourceforge.net/projects/gnude">gnude - gnu development environment</a>,
currently an arm/newlib cross toolchain compiled for Windows, but aiming to do more
<li>
My <a href="http://kegel.com/xgcc3">older cross compiler stuff</a> is still
online. This is where I documented the patches needed to run on ppc405;
these patches are included in my glibc-2.2.5/gcc-3.2.3 patches collection,
and some of them have made it in to gcc-3.3.
</ul>
Here are a few posts about which combinations of versions work:
<ul>
<li><a href="../buildlogs/index.html">crosstool's build results</a> - yeah, I linked to them above, but they bear repeating
<li><a href="http://sources.redhat.com/ml/crossgcc/2004-05/msg00036.html">host cygwin, target ARM</a> - scroll down to matrix at bottom
</ul>
Related Mailing lists (corrections welcome):
<ul>
<li>General: <a href="http://sources.redhat.com/ml/crossgcc/">crossgcc</a> (for crosstool), and
<a href="http://www.embeddedtux.org/mlist.html">embeddedtux</a> (for do-it-yourselfers who don't use a canned script like crosstool)
<li>Alpha: <a href="https://www.redhat.com/mailman/listinfo/axp-list">axp-list</a>
<li>ARM: <a href="http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-toolchain">linux-arm-toolchain</a>
<li>HPPA: <a href="http://www.parisc-linux.org/mailing-lists/">parisc-linux</a>
<li>MIPS: <a href="http://www.linux-mips.org/wiki/Net_Resources#Mailing_lists">linux-mips</a>
<li>PowerPC: <a href="http://lists.linuxppc.org/linuxppc-embedded/">linuxppc-embedded</a>,
<a href="http://ozlabs.org/pipermail/linuxppc-dev/">linuxppc-dev</a>
<li>PowerPC64: <a href="http://ozlabs.org/pipermail/linuxppc64-dev/">linuxppc64-dev</a>
<li>SH: <a href="http://tsukuba.m17n.org/linux-sh/ml/linux-sh/">linux-sh</a>, <a href="http://sourceforge.net/mailarchive/forum.php?forum=linuxsh-dev">linuxsh-dev</a>
<li>S/390: <a href="http://www2.marist.edu/htbin/wlvindex?linux-390">linux-390</a>
<li>sparc: <a href="http://vger.kernel.org/vger-lists.html#sparclinux">sparclinux</a>
<li>x86_64: <a href="http://www.x86-64.org/mailinglists">discuss@x86-64.org</a>
</ul>
<p>
<hr>
Portions copyright 2003, <a href="http://ixiacom.com">Ixia Communications</a><br>
Portions copyright 2003, 2004, 2005 <a href="http://google.com">Google</a><br>
Released under the GPL.<br>
Last revision 2 Mar 2006 by dank@kegel.com
</body>
</html>
|
