Ниже изложена процедура установки GNU CC в системе Unix. См. раздел [Установка на VMS], для VMS систем. В этом разделе мы считаем, что вы компилируете в том же каталоге, который содержит исходные фай- лы; см. раздел [Другие Директории], чтобы выяснить, как компилировать в отдельном каталоге в системе Unix.
Вы не можете установить GNU C с помощью его самого в MS-DOS. Он не будет компилироваться никаким компилятором MS-DOS кроме его самого. Вы должны получить полный пакет компиляции DJGPP, который включает двоичные файлы, также как и исходные, и включает все необходимые инструментальные средства для компиляции и библиотеки.
./configure --build=sparc-sun-sunos4.1
Если вы будете использовать GNU CC с ассемблером GNU (GAS), вы должны указать это с помощью `--c-gnu-as' опцией когда вы запускаете `configure'.
Использование этой опции не устанавливает GAS. Она только изменяет вывод GNU CC, чтобы он работал с GAS. Построение и установка GAS - это ваша задача.
Наоборот, если вы не хотите использовать GAS и не определяете `--with-gnu-as' при построении GNU CC, это ваша задача - удостовериться, что GAS не установлен. GNU CC ищет программу с именем as в различных каталогах; если программа, которую он находит - GAS, тогда он запускает GAS. Если вы не уверены, где GNU CC находит ассемблер, который он использует, попробуйте указать `-v', когда вы его запускаете.
Системы где важно, используете ли вы GAS: `hppa1.0-любая-любая', `hppa1.1-любая-любая', `i386-любая-sysv', `i386-любая-isc', `i860-любая-bsd', `m68k-bull-sysv', `m68k-hp-hpux', `m68k-sony-bsd', `m68k-altos-sysv', `m68000-hp-hpux', `m68000-att-sysv', `ANY-lynx-lynxos' и `mips-любая'). В любой другой системе `--with-gnu-as' не имеет никакого эффекта.
В системах перечисленных выше (кроме HP-PA, ISC на 386 и `mips-sgi-irix5.*'), если вы используете GAS, вы должны, также, использовать GNU линкер (и указывать `--with-gnu-ld').
Укажите опцию `--with-gnu-ld', если вы планируете использовать GNU линкер с GNU CC.
Эта опция не заставляет устанавливать GNU линкер; она только изменяет поведение GNU CC, чтобы он работал с GNU линкером. В частности, она запрещает установку `collect2' - программы, которая в противном случае служит в качестве внешнего интерфейса для линкера системы в большинстве конфигураций.
В системах, основанных на MIPS, и в системах на Alpha вы должны определять, должен ли GNU CC создавать нормальный отладочный формат ECOFF или использовать stab'ы BSD-стиля, передаваемые через символьную таблицу ECOFF. Нормальный отладочный формат ECOFF не может полностью обрабатывать языки, отличные от C. Формат BSD stab'ов может обрабатывать другие языки, но он работает только с отладчиком GNU - GDB.
Обычно, GNU CC использует отладочный формат ECOFF по умолчанию; если вы предпочитаете BSD stab'ы, укажите `--with-stabs', когда вы конфигурируете GNU CC.
Вне зависимости от того, какое умолчание вы выбираете, когда конфигурируете GNU CC, пользователь может использовать опции `-gcoff' и `-gstabs+', чтобы явно указывать отладочный формат для конкретной компиляции.
`--with-stabs' имеет значение также в системе ISC на 386, если используется '--with-gas'. Она включает применение отладочной информация stab'ов, встроенной в вывод COFF'а. Этот вид отладочной информации хорошо поддерживает C++; обычная отладочная информация COFF'а не делает этого.
`--with-stabs' имеет значение также в системах на 386, исполняющих SVR4. Она включает применение отладочной информация stab'ов, встроенной в вывод ELF'а. C++ компилятор в настоящее время (2.6.0) не поддерживает отладочную информацию DWARF, обычно используемую на 386 SVR4 платформах; stab'ы обеспечивают работающий вариант. Он требует gas и gdb, поскольку обычные инструментальные средства SVR4 не могут генерировать или интерпретировать stab'ы.
В некоторых системах вы должны указывать, имеет ли машина модуль плавающей точки. Эти системы включают `m68k-sun-sunos n' и `m68k-isi-bsd'. В любой другой системе, `--nfp' в настоящее время не имеет никакого эффекта, хотя, возможно, имеются другие системы, где она могла бы быть полезна.
make stage1
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2"
make stage2
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"
make compare
make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST"
Ниже перечислены возможный типы центральных процессоров:
1750a, a29k, alpha, arm, cN, clipper, dsp16xx, elxsi, h8300,
hppa1.0, hppa1.1, i370, i386, i486, i586, i860, i960, m68000, m68k,
m88k, mips, mipsel, mips64, mips64el, ns32k, powerpc, powerpcle,
pyramid, romp, rs6000, sh, sparc, sparclite, sparc64, vax, we32k.
acorn, alliant, altos, apollo, att, bull, cbm, convergent, convex,
crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp, ibm,
intergraph, isi, mips, motorola, ncr, next, ns, omron, plexus,
sequent, sgi, sony, sun, tti, unicom, wrs.
Имя компании имеет значение только для разрешения неоднозначностей, когда остальной указанной информации недостаточно. Вы можете опускать его, записывая только `процессор-система', если оно не необходимо. Например, `vax-ultrix4.2' эквивалентно `vax-dec-ultrix4.2'.
Ниже расположен список типов систем:
386bsd, aix, acis, amigados, aos, aout, bosx, bsd, clix, coff,
ctix, cxux, dgux, dynix, ebmon, ecoff, elf, esix, freebsd, hms,
genix, gnu, gnu/linux, hiux, hpux, iris, irix, isc, luna, lynxos,
mach, minix, msdos, mvs, netbsd, newsos, nindy, ns, osf, osfrose,
ptx, riscix, riscos, rtu, sco, sim, solaris, sunos, sym, sysv,
udi, ultrix, unicos, uniplus, unos, vms, vsta, vxworks, winnt,
xenix.
Вы можете опустить тип системы, тогда `configure' догадывается об операционной системе из процессора и компании.
Вы можете добавлять номер версии к типу системы; это может или не может давать различие. Например, вы можете писать `bsd4.3' или `bsd4.4', чтобы отличать версии BSD. Практически, номер версии наиболее необходим для `sysv3' и `sysv4', которые часто обрабатываются по-разному.
Если вы определяете невозможную комбинацию типа `i860-dg-vms', вы можете получить сообщение об ошибке от `configure', или же он может игнорировать часть информации и сделать лучшее, что возможно с остальным. `configure' всегда печатает каноническиое имя для варианта, который он использовал. GNU CC не обеспечивает все возможные варианты.
Часто индивидуальная модель машины имеет имя. Многие машинные имена распознаются как псевдонимы для комбинаций процессор/компания. Имеется таблица известных машинных имен:
3300, 3b1, 3bN, 7300, altos3068, altos, apollo68, att-7300,
balance, convex-cN, crds, decstation-3100, decstation, delta,
encore, fx2800, gmicro, hp7NN, hp8NN, hp9k2NN, hp9k3NN, hp9k7NN,
hp9k8NN, iris4d, iris, isi68, m3230, magnum, merlin, miniframe,
mmax, news-3600, news800, news, next, pbd, pc532, pmax, powerpc,
powerpcle, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3,
sun4, symmetry, tower-32, tower.
Таким образом, если вы указываете `m68k-local', конфигурация использует файлы `m68k.md', `local.h', `m68k.c', `xm-local.h', `t-local' и `x-local', все в каталоге `config/m68k'.
Если вы хотите построить объектные и выполнимые файлы в каталоге отличном, от содержащего исходные файлы, ниже указано, что вы должны делать по-другому:
make distclean
mkdir gcc-sun3
cd gcc-sun3
../gcc/configure ...
../gcc/configure - srcdir= ../gcc другое опции
GNU CC может функционировать как кросскомпилятор для многих машин, но не для всех.
Поскольку GNU CC генерирует ассемблерный код, вы, вероятно, нуждаетесь в кроссассемблере, чтобы GNU CC мог выполняться, порождая объектные файлы. Если вы хотите линковать не на целевой машине, вы к тому же нуждаетесь в кросслинкере. Вы также нуждаетесь в заголовочных файлах и библиотеках, подходящих для целевой машины, которые вы можете установить на хост-машине.
Компиляция и выполнение программ с использованием кросскомпилятора включает несколько шагов:
Чтобы построить GNU CC как кросскомпилятор, вы начинаете с выполнения `configure'. Используйте `--target=цель', чтобы указать тип целевой машины. Если `configure' оказался неспособен правильно идентифицировать систему, на которой вы его выполняете, также укажите '--build=строющая'. Например, ниже показано, как конфигурировать кросскомпилятор, который производит код для системы HP 68030 с системой BSD, которую `configure' может правильно идентифицировать:
./configure --target=m68k-hp-bsd4.3
Если у вас есть кроссассемблер и кросслинкер, вы должны их теперь установить. Поместите их в каталог `/usr/local/цель/bin'. Имеется таблица инструментальных средств, которые вы должны включить в этот каталог:
Это должен быть кроссассемблер.
Это должен быть кросслинкер.
Это должен быть кроссархиватор: программа, которая может управлять архивными файлами (библиотеками линкера) в формате целевой машины.
Это должна быть программа для создания таблицы идентификаторов в архивном файле.
Самый простой способ обеспечивать эти файлы состoит в том, чтобы построить пакет Binutils и GAS. Cконфигурируйте их с теми же самыми `--host' и '--target', которые вы используете для конфигурирования GNU CC, затем постройте и установите их. Они устанавливают свои выполнимые файлы автоматически в соответствующий каталог. Но они не поддерживают все целевые машины, которые поддерживает GNU CC.
Если вы хотите установить библиотеки, чтобы использовать с кросскомпилятором, такие, как стандарная библиотека C, поместите их в каталог `/usr/local/цель/lib'; установка GNU CC копирует все файлы в этом подкаталоге в соответствующее место, чтобы GNU CC мог находить их и линковать с ними. Ниже показан пример копирования некоторого количества библиотек с целевой машины:
ftp целевая-машина
lcd /usr/local/цель/lib
cd /lib
get libc.a
cd /usr/lib
get libg.a
get libm.a
quit
Многие целевые машины требуют "файлы начала" типа `crt0.o' и `crtn.o', которые линкуются к каждому выполнимому файлу; они также должны помещаться в `/usr/local/цель/lib'. Могут иметься несколько вариантов для `crt0.o', для применения с профиляцией или другими опциями компиляции. Ниже показан пример копирования этих файлов с целевой машины:
ftp целевая-машина
lcd /usr/local/цель/lib
prompt
cd /lib
mget *crt*.o
cd /usr/lib
mget *crt*.o
quit
Сейчас вы можете продолжить также, как и при построении компилятора для одной машины построением stage 1. Если вы обеспечили какой-либо вариант 'libgcc1.a'. тогда компиляция будет прервана в точке, где нужен этот файл,
означает одно и то же для родного и кросс- компиляторов. Это место, где GNU CC сохраняет свои личные заголовочные файлы, а также где GNU CC сохраняет фиксированные заголовочные файлы. Кросскомпилирующий GNU CC запускает fixincludes над заголовочными файлами в '$(tooldir)/include'. (Если заголовочные файлы кросскомпиляции должны быть зафиксированы, они должны быть установлены до построения GNU CC. Если заголовочные файлы кросскомпиляции уже доступны для ANSI C и GNU CC, ничего специально делать не нужно.)
означает одно и то же для родного и кросс- компиляторов. Это место, где g++ смотрит в первую очередь, в поисках заголовочных файлов. libg++ устанавливает только машинонезависимые заголовочные файлы в этой директории.
используется только для родного компилятора. Обычно это '/usr/local/include'. GNU CC просматривает эту директорию, так что пользователи могут устанавливать заголовочные файлы в '/usr/local/include'.
используется только для кросскомпилятора. GNU CC ничего здесь не устанавливает.
используется как для родного, так и для кросскомпиляторов. Это место для инсталляции заголовочных файлов для других пакетов, которое GNU CC будет использовать. Для кросскомпилятора это '/usr/include'. Когда вы строите кросскомпилятор fixincludes обрабатывает все заголовочные файлы в этом каталоге.