Установка GNU CC

Ниже изложена процедура установки GNU CC в системе Unix. См. раздел [Установка на VMS], для VMS систем. В этом разделе мы считаем, что вы компилируете в том же каталоге, который содержит исходные фай- лы; см. раздел [Другие Директории], чтобы выяснить, как компилировать в отдельном каталоге в системе Unix.

Вы не можете установить GNU C с помощью его самого в MS-DOS. Он не будет компилироваться никаким компилятором MS-DOS кроме его самого. Вы должны получить полный пакет компиляции DJGPP, который включает двоичные файлы, также как и исходные, и включает все необходимые инструментальные средства для компиляции и библиотеки.

Если вы предварительно построили GNU CC в том же самом каталоге для другой целевой машины, сделайте `make distclean', чтобы удалить все файлы, которые могут быть неправильными. Один из удаляемых файлов - `Makefile'; если `make distclean' говорит, что `Makefile' не существует, это, вероятно, означяет, что каталог уже правильно очищен.
В системе System V release 4, удостоверьтесь, что `/usr/bin' предшествует `/usr/ucb' в PATH. Команда 'cc' в `/usr/ucb' использует библиотеки, которые содержат ошибки.
Укажите хост, формирующую и целевую машинные конфигурации. Вы делаете это при выполнении файла `configure'. "Формирующая" машина - система которую вы используете, "хост" машина - система, где вы хотите выполнять получающийся в результате компилятор (обычно, формирующая машина), "целевая" машина - система, для которой вы хотите, чтобы компилятор генерировал код. Если вы строите компилятор, чтобы генерировать код для машины, на которой выполняется компилятор (родной компилятор), вы, обычно, не должны указывать никаких операндов configure; он попробует определить тип машины, на которой вы работаете, и использовать ее в качестве формирующей, главной и целевой машин. Так что вы не должны указывать конфигурацию, когда строится родной компилятор, разве что configure не может определить вашу конфигурацию или определяет ее неправильно. В этих случаях, укажите имя конфигурации формирующей машины с опцией '--build', главная машина и адресат будут по умолчанию такими же как и формирующая машина. (Если вы строите кросскомпилятор, см. раздел [Построение и Установка Кросскомпилятора].) Пример:
```
        ./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'.

'--with-gnu-as'
Если вы будете использовать 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'
Укажите опцию `--with-gnu-ld', если вы планируете использовать GNU линкер с GNU CC.
Эта опция не заставляет устанавливать GNU линкер; она только изменяет поведение GNU CC, чтобы он работал с GNU линкером. В частности, она запрещает установку `collect2' - программы, которая в противном случае служит в качестве внешнего интерфейса для линкера системы в большинстве конфигураций.

`--with-stabs'
В системах, основанных на 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'ы.

`--nfp'
В некоторых системах вы должны указывать, имеет ли машина модуль плавающей точки. Эти системы включают `m68k-sun-sunos n' и `m68k-isi-bsd'. В любой другой системе, `--nfp' в настоящее время не имеет никакого эффекта, хотя, возможно, имеются другие системы, где она могла бы быть полезна.
`configure' просматривает подкаталоги исходного каталога в поисках других компиляторов, которые должны интегрироваться в GNU CC. GNU компилятор для C++, называемый G++ находится в подкаталоге с именем `cp'. `configure' вставляет правила в `Makefile' для построения всех этих компиляторов. Далее мы перечисляем файлы, которые будут устанавливаться `configure'. Обычно вы не должны иметь дело с этими файлами.
- Создается файл с именем `config.h', который содержит директиву `#include' файла конфигурации верхнего уровня для машины, на которой вы будете запускать компилятор (см. Главу 18 [Конфигурация]). Этот файл отвечает за определение информации о хост-машине. Он включает `tm.h'. Файл конфигурации верхнего уровня размещается в подкаталоге `config'. Его имя - всегда `xm-что-нибудь.h'; обычно `xm-машина.h', но имеется некоторое количество исключений. Если ваша система не поддерживает символические ссылки, вы можете захотеть заставить `config.h' содержать директиву `#include', которая относится к соответствующему файлу.
- Создается файл с именем `tconfig.h`, который включает конфигурационный файл верхнего уровня для вашей целевой машины. Это используется для компиляции некоторых программ для выполнения на этой машине.
- Создается файл с именем `tm.h`, который включает макрофайл описания архитектуры для вашей целевой машины. Он должен быть в поддиректории `config` и его именем часто является `машина.h`.
- Командный файл `configure` также конструирует файл `Makefile` с помощью добавления некоторого текста к файлу-шаблону `Makefile.in`. Дополнительный текст приходит из файлов в каталоге `config` с именами `t-целевая` и `x-хост`. Если эти файлы не существуют, то это означает, что ничего не должно добавляться для данной целевой или хост-машины.
Стандартным каталогом для инсталляции GNU CC является '/usr/local/lib'. Если вы хотите установить его файлы где-нибудь в другом месте, '--prefix=каталог' при запуске 'configure'. Здесь 'каталог' - имя каталога, используемого вместо '/usr/local' для всех целей кроме одной: каталог '/usr/local/include' используется для поиска заголовочных файлов, вне зависимости от того, где вы установили компилятор. Чтобы переменить это имя, используйте опцию --local-prefix, указанную ниже.
Укажите '--local-prefix=каталог', если вы хотите, чтобы компилятор использовал каталог 'каталог/include' для поиска локально установленных заголовочных файлов вместо '/usr/local/include'. Вы должны указать `--local-prefix=директория', только если ваша система имеет другое соглашение (не `/usr/local') для того, где помещать файлы, специфические для ситемы. Не указывайте `/usr' как `--local-prefix'! Каталог, который вы используете для `--local-prefix' не должен содержать ни один из стандартных заголовочных файлов системы. Если он содержал их, то некоторые программы не будут компилироваться (включая GNU Emacs, на некоторых целевых машинах), потому что это будет отменять и аннулировать исправления заголовочных файлов, сделанные fixincludes.
Удостоверьтесь, что генератор синтаксических анализаторов Bison установлен. (Это необязательно, если выходные файлы Bison `c-parse.c' и `cexp.c' являются более поздними чем `c-parse.y' и `cexp.y', и вы не планируете изменять `.y' файлы.) Bison версии, более старой чем 8 сентября 1988 года, будет производить неправильный вывод для `c-parse.c'.
Если вы выбрали конфигурацию для GNU CC, которая требует других инструментальных средств GNU (типа GAS или линкера GNU) вместо стандартных инструментальных средств системы, установите требуемые инструментальные средства в формируемом каталоге под именами `as', `ld' или другими. Это будет давать возможность компилятору находить соответствующие инструментальные средства для трансляции программы `enquire'. В качестве альтернативы, вы можете производить последующую трансляцию, используя значение системной переменной PATH, такое, что необходимые инструментальные средства GNU стоят до стандартных инструментальных средств системы.
Постройте компилятор. Просто напечатайте `make LANGUAGES=c' в каталоге компилятора. `LANGUAGES=c' указывает, что должен компилироваться только компилятор C. Makefile обычно строит компиляторы для всех поддерживаемых языков; в настоящее время - C, C++ и Objective C. Однако, C - единственый язык, который точно будет работать, если вы строите его с помощью другого, не GNU C компилятора. Кроме того, при построении чего-нибудь другого кроме C на этой стадии - трата времени. В общем, вы можете указать языки, которые нужно строить, указывая параметр `LANGUAGES= "список"', где 'список' - одно или более слов из списка `c', `c++' и `objective-c'. Если вы имеете какие-либо дополнительные компиляторы GNU как подкаталоги исходного каталога GNU CC, вы можете также указать их имена в этом списке. Игнорируйте любые предупреждения, которые вы можете увидеть относительно "statement not reached" в `insn-emit.c' - они нормальны. Аналогично, предупреждения относительно "unknown escape sequence" нормальны в `genopinit.c' и, возможно, в некоторых других файлах. Аналогично, вы должны игнорировать предупреждения относительно "constant is so large that it is unsigned" в `insn-emit.c' и `insn-recog.c' и предупреждение относительно сравнения, всегда равного нулю, в `enquire.o'. Любые другие ошибки компиляции могут представлять собой ошибки в переносе на вашу машину или операционную систему и должны быть исследованы и сообщены.
Если вы строите кросскомпилятор, остановитесь здесь. См. Раздел [Построение и Установка Кросскомпилятора].
Переместите объектные и исполнимые файлы первой стадии в подкаталог с помощью команды:
```
           make stage1
```
Файлы перемещаются в подкаталог с именем `stage1'. После того, как установка будет закончена, вы можете захотеть удалить эти файлы с помощью команды `rm -r stage1'.
Если вы выбрали конфигурацию для GNU CC, которая требует других инструментальных средств GNU (типа GAS или линкера GNU) вместо стандартных инструментальных средств системы, установите требуемые инструментальные средства в подкаталоге 'stage1' под именами `as', `ld' или другими. Это будет давать возможность стадии 1 компилятора находить соответствующие инструментальные средства на последующих стадиях. В качестве альтернативы, вы можете производить последующую трансляцию, используя значение системной переменной PATH, такое, что необходимые инструментальные средства GNU стоят до стандартных инструментальных средств системы.
Перекомпилируйте компилятор с помощью его самого командой:
```
           make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2"
```
Это называется созданием стадии 2 компилятора.
Если вы хотите проверить компилятор, компилируя его самим собой несколько раз, установите все остальные необходимые инструментальные средства GNU (типа GAS или линкера GNU) в подкаталог `stage2', как вы делали в подкаталоге `stage1', затем сделайте так:
```
           make stage2
           make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"
```
Это называется созданием стадии 3 компилятора. Кроме опции `-B', опции компилятора должны быть такими же самыми, как когда вы строили стадию 2 компилятора.
Затем сравните последние объектные файлы с объектными файлами стадии 2 - они должны быть идентичными, кроме временных меток (если есть). Используйте эту команду для сравнения файлов:
```
           make compare
```
Она будет упоминать любые объектные файлы, которые отличаются в стадиях 2 и 3. Любое различие, неважно насколько малое, указывает на то, что стадия 2 компилятора, компилировалась GNU CC неправильно, и следовательно существует потенциально серьезная ошибка, которую вы должны исследовать.
Установите управляющую программу компилятора, проходы компилятора и средства динамической поддержки с помощью `make install'. Используйте то же самое значение для `CC', `CFLAGS' и `LANGUAGES', которое вы использовали при компиляции файлов, которые устанавливались. Одна из причин, по которой это необходимо - то, что некоторые версии make имеют ошибки и перекомпилируют файлы, когда вы делаете этот шаг. Если вы используете те же самые значения переменных, то файлы будут перекомпилироваться правильно. Например, если вы построили стадию 2 компилятора, вы можете использовать следующую команду:
```
 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', так что она появляется в типичном маршруте поиска выполнения.

3.1 Конфигурации Поддерживаемые GNU CC

Ниже перечислены возможный типы центральных процессоров:

      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'.

3.2 Компиляция в Отдельном Каталоге

Если вы хотите построить объектные и выполнимые файлы в каталоге отличном, от содержащего исходные файлы, ниже указано, что вы должны делать по-другому:

Удостоверьтесь, что вы имеете версию Make, которая поддерживает возможность `VPATH'. (GNU Make поддерживает ее, как и версии Make на большинстве систем BSD.)
Если вы когда-либо выполняли `configure' в исходном каталоге, вы должны отменить конфигурацию. Сделайте это выполнением:
```
    make distclean
```
Перейдите в каталог, в котором вы хотите построить компилятор перед выполнением `configure':
```
           mkdir gcc-sun3
           cd gcc-sun3
```
В системах, которые не поддерживают символические ссылки, этот каталог должен быть в той же файловой системе, что и каталог исходных текстов.
Укажите, где находить `configure', когда вы его выполняете:
```
           ../gcc/configure ...
```
Это также сообщает `configure', где находить исходники компилятора; `configure' берет каталог из имени файла, которое использовалось, чтобы вызывать его. Но если вы хотите быть уверенными, вы можете указать исходный каталог с помощью опции `--srcdir' :
```
           ../gcc/configure - srcdir= ../gcc другое опции
```
Каталог, который вы указываете с `--srcdir' не обязан быть тем же каталогом, в котором находится `configure'. Теперь, вы можете запускать `make' в этом каталоге. Вы не должны повторять шаги конфигурации показанные выше, при обычном изменении исходных файлов. Вы должны, однако, выполнить `configure' снова, при изменении файлов конфигурации, если ваша система не поддерживает символические ссылки.

3.3 Построение и Установка Кросскомпилятора

GNU CC может функционировать как кросскомпилятор для многих машин, но не для всех.

Кросскомпиляторы между машинами с различными форматами плавающей точки не все сделаны работающими. GNU CC теперь имеет эмулятор плавающей точки, с которым они могут работать, но каждое описание целевой машины должно быть модифицировано, чтобы воспользоваться этим преимуществом.
Кросскомпиляция между машинами с различными размерами слов несколько проблематична и иногда не работает.

Поскольку GNU CC генерирует ассемблерный код, вы, вероятно, нуждаетесь в кроссассемблере, чтобы GNU CC мог выполняться, порождая объектные файлы. Если вы хотите линковать не на целевой машине, вы к тому же нуждаетесь в кросслинкере. Вы также нуждаетесь в заголовочных файлах и библиотеках, подходящих для целевой машины, которые вы можете установить на хост-машине.

Шаги Кросскомпиляции

Компиляция и выполнение программ с использованием кросскомпилятора включает несколько шагов:

Запуск кросскомпилятора на хост-машине для порождения ассемблерных файлов для целевой машины. Это требует заголовочных файлов для целевой машины.
Компиляция файлов, произведенных кросскомпилятором. Вы можете делать это или ассемблером на целевой машине, или кроссассемблером на хост-машине.
Линковка этих файлов, чтобы сделать выполнимый файл. Вы можете делать это также линкером на целевой машине, или кросслинкером на хост-машине. Какую бы машину вы не использовали, вы нуждаетесь в библиотеках и в определенных стартовых файлах (обычно `crt....o') для целевой машины.

Наиболее удобно делать все эти шаги на одной и той же главной машине, поскольку вы можете делать это все одним вызовом GNU CC. Это требует подходящего кроссассемблера и кросслинкера. Для некоторых целевых машин GNU ассемблер и линкер доступны.

Конфигурирование Кросскомпилятора

Чтобы построить GNU CC как кросскомпилятор, вы начинаете с выполнения `configure'. Используйте `--target=цель', чтобы указать тип целевой машины. Если `configure' оказался неспособен правильно идентифицировать систему, на которой вы его выполняете, также укажите '--build=строющая'. Например, ниже показано, как конфигурировать кросскомпилятор, который производит код для системы HP 68030 с системой BSD, которую `configure' может правильно идентифицировать:

      ./configure --target=m68k-hp-bsd4.3

Инструментальные Средства и Библиотеки для Кросскомпилятора

Если у вас есть кроссассемблер и кросслинкер, вы должны их теперь установить. Поместите их в каталог `/usr/local/цель/bin'. Имеется таблица инструментальных средств, которые вы должны включить в этот каталог:

`as'

Это должен быть кроссассемблер.

`ld'

Это должен быть кросслинкер.

`ar'

Это должен быть кроссархиватор: программа, которая может управлять архивными файлами (библиотеками линкера) в формате целевой машины.

`ranlib'

Это должна быть программа для создания таблицы идентификаторов в архивном файле.

Установка GNU CC будет находить эти программы в этом каталоге и копировать или компоновать их в соответствующие места для кросскомпилятора, чтобы он находил их позже при выполнении.

Самый простой способ обеспечивать эти файлы сост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'. тогда компиляция будет прервана в точке, где нужен этот файл,

3.4 Стандартные Директории Заголовочных Файлов

GCC_INCLUDE_DIR

означает одно и то же для родного и кросс- компиляторов. Это место, где GNU CC сохраняет свои личные заголовочные файлы, а также где GNU CC сохраняет фиксированные заголовочные файлы. Кросскомпилирующий GNU CC запускает fixincludes над заголовочными файлами в '$(tooldir)/include'. (Если заголовочные файлы кросскомпиляции должны быть зафиксированы, они должны быть установлены до построения GNU CC. Если заголовочные файлы кросскомпиляции уже доступны для ANSI C и GNU CC, ничего специально делать не нужно.)

GPLUS_INCLUDE_DIR

означает одно и то же для родного и кросс- компиляторов. Это место, где g++ смотрит в первую очередь, в поисках заголовочных файлов. libg++ устанавливает только машинонезависимые заголовочные файлы в этой директории.

LOCAL_INCLUDE_DIR

используется только для родного компилятора. Обычно это '/usr/local/include'. GNU CC просматривает эту директорию, так что пользователи могут устанавливать заголовочные файлы в '/usr/local/include'.

CROSS_INCLUDE_DIR

используется только для кросскомпилятора. GNU CC ничего здесь не устанавливает.

TOOL_INCLUDE_DIR

используется как для родного, так и для кросскомпиляторов. Это место для инсталляции заголовочных файлов для других пакетов, которое GNU CC будет использовать. Для кросскомпилятора это '/usr/include'. Когда вы строите кросскомпилятор fixincludes обрабатывает все заголовочные файлы в этом каталоге.

Исходники

Другое