| |
Ниже изложена процедура установки GNU CC в системе Unix. См. раздел [Установка на VMS], для VMS систем. В этом разделе мы считаем, что вы компилируете в том же каталоге, который содержит исходные фай- лы; см. раздел [Другие Директории], чтобы выяснить, как компилировать в отдельном каталоге в системе Unix.
Вы не можете установить GNU C с помощью его самого в MS-DOS. Он не будет компилироваться никаким компилятором MS-DOS кроме его самого. Вы должны получить полный пакет компиляции DJGPP, который включает двоичные файлы, также как и исходные, и включает все необходимые инструментальные средства для компиляции и библиотеки.
./configure --build=sparc-sun-sunos4.1
Имя конфигурации может быть каноническим или более или менее
сокращенным.
Каноническиое имя конфигурации имеет три части, разделяемые
черточкой.
Оно выглядит следующим образом: `процессор-компания-система'.
(Три части могут сами содержать черточки, `configure' может выяснить,
какие черточки служат каким целям.) Например, `m68k-sun-sunos4.1'
определяет Sun 3.
Вы можете также заменять части конфигурации на прозвища или
псевдонимы. Например, `sun3' заменяет `m68k-sun', так
`sun3-sunos4.1' - другой способ указать Sun 3. Вы можете также
использовать просто `sun3-sunos', так как версия SunOS считается по
умолчанию равной четырем. `sun3-bsd' также работает, так как
`configure' знает, что единственный вариант BSD на Sun 3 - SunOS.
Вы можете указать номер версии после любого из типов систем и
после некоторых из типов процессоров. В большинстве случаев, версия
неуместна и игнорируется. Так что вы могли к тому же указать версию,
если вы знаете ее.
См. раздел [Конфигурации], за списком поддерживаемых имен конфи-
гураций и примечаний относительно многих из них. Вы должны посмотреть
примечания в этом разделе перед выполнением любых дальнейших действий
по установке GNU CC.
Имеются четыре дополнительные опции, которые вы можете указать
независимо, чтобы определить варианты аппаратных и программных
конфигураций. Это - `--with-gnu-as', `--with-gnu-ld', `--with-stabs' и
`--nfp'.
Если вы будете использовать 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
Файлы перемещаются в подкаталог с именем `stage1'. После того,
как установка будет закончена, вы можете захотеть удалить эти файлы с
помощью команды `rm -r stage1'.
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2"
Это называется созданием стадии 2 компилятора.
make stage2
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"
Это называется созданием стадии 3 компилятора. Кроме опции `-B',
опции компилятора должны быть такими же самыми, как когда вы строили
стадию 2 компилятора.
make compare
Она будет упоминать любые объектные файлы, которые отличаются в
стадиях 2 и 3. Любое различие, неважно насколько малое, указывает на
то, что стадия 2 компилятора, компилировалась GNU CC неправильно, и
следовательно существует потенциально серьезная ошибка, которую вы
должны исследовать.
make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST"
Она копирует файлы `cc1', `cpp' и `libgcc.a' в файлы `cc1', `cpp'
и `libgcc.a' в каталоге `/usr/local/lib/gcc-lib/цель/версия' - тот, в
котором управляющая программа компилятора ищет их. Здесь 'цель' - тип
целевой машины, указанный, когда вы выполняли `configure', а 'версия'
- номер версии GNU CC.
Она также копирует управляющую программу `xgcc' в
`/usr/local/bin/gcc', так что она появляется в типичном маршруте
поиска выполнения.
Ниже перечислены возможный типы центральных процессоров:
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.
Не забудьте, что машинное имя определяет и тип центрального
процессора, и имя компании. Если вы хотите устанавливать ваши
собственные файлы конфигурации собственного производства, вы можете
использовать `local' как имя компании, чтобы обращаться к ним. Если вы
используете конфигурацию `процессор-local', то имя конфигурации без
префикса процессора используется, чтобы сстроить имя файла
конфигурации.
Таким образом, если вы указываете `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 ...
Это также сообщает `configure', где находить исходники
компилятора; `configure' берет каталог из имени файла, которое
использовалось, чтобы вызывать его. Но если вы хотите быть уверенными,
вы можете указать исходный каталог с помощью опции `--srcdir' :
../gcc/configure - srcdir= ../gcc другое опции
Каталог, который вы указываете с `--srcdir' не обязан быть тем же
каталогом, в котором находится `configure'.
Теперь, вы можете запускать `make' в этом каталоге. Вы не должны
повторять шаги конфигурации показанные выше, при обычном изменении
исходных файлов. Вы должны, однако, выполнить `configure' снова, при
изменении файлов конфигурации, если ваша система не поддерживает
символические ссылки.
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 обрабатывает все заголовочные файлы в этом каталоге.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |