Нижче викладена процедура установки GNU CC в системі Unix. Див. Розділ [Установка на VMS], для VMS систем. У цьому розділі ми вважаємо, що ви компілюєте в тому ж каталозі, який містить вихідні фай- ли; см. розділ [Інші Директорії], щоб з'ясувати, як компілювати в окремому каталозі в системі Unix.
Якщо ви будете використовувати 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'и.
Нижче перераховані можливий типи центральних процесорів:
Нижче перераховані розпізнаються імена компаній. Як ви можете бачити, звичайні скорочення використовуються частіше, ніж довші офіційні імена.
Ім'я компанії має значення тільки для вирішення неоднозначностей, коли решта зазначеної інформації недостатньо. Ви можете опускати його, записуючи тільки `процесор-система ', якщо воно не потрібно. Наприклад, `vax-ultrix4.2 'еквівалентно` vax-dec-ultrix4.2'.
Нижче розташований список типів систем:
Ви можете опустити тип системи, тоді `configure 'здогадується про операційну систему з процесора і компанії.
Ви можете додавати номер версії до типу системи; це може або не може давати відмінність. Наприклад, ви можете писати `bsd4.3 'або` bsd4.4', щоб відрізняти версії BSD. Практично, номер версії найбільш необхідний для `sysv3 'і` sysv4', які часто обробляються по-різному.
Якщо ви визначаєте неможливу комбінацію типу `i860-dg-vms ', ви можете отримати повідомлення про помилку від` configure', або ж він може ігнорувати частина інформації і зробити краще, що можливо з іншим. `Configure 'завжди друкує канонічного ім'я для варіанта, який він використовував. GNU CC не забезпечує всі можливі варіанти.
Часто індивідуальна модель машини має ім'я. Багато машинні імена розпізнаються як псевдоніми для комбінацій процесор / компанія. Є таблиця відомих машинних імен:
Не забудьте, що машинне ім'я визначає і тип центрального процесора, і ім'я компанії. Якщо ви хочете встановлювати ваші власні файли конфігурації власного виробництва, ви можете використовувати `local 'як ім'я компанії, щоб звертатися до них. Якщо ви використовуєте конфігурацію `процесор-local ', то ім'я конфігурації без префікса процесора використовується, щоб сстроіть ім'я файлу конфігурації.
Таким чином, якщо ви вказуєте `m68k-local ', конфігурація використовує файли` m68k.md', `local.h ',` m68k.c', `xm-local.h ',` t-local' і `x- local ', все в каталозі `config / m68k'.
Якщо ви хочете побудувати об'єктні і виконувані файли в каталозі відмінному, від що містить вихідні файли, нижче зазначено, що ви повинні робити по-іншому:- Переконайтеся, що ви маєте версію Make, яка підтримує можливість `VPATH '. (GNU Make підтримує її, як і версії Make на більшості систем BSD.)
- Якщо ви коли-небудь виконували `configure 'у вихідному каталозі, ви повинні скасувати конфігурацію. Зробіть це виконанням:
- Перейдіть в каталог, в якому ви хочете побудувати компілятор перед виконанням `configure ': У системах, які не підтримують символічні посилання, цей каталог повинен бути в тій же файлової системи, що і каталог вихідних текстів.
- Вкажіть, де знаходити `configure ', коли ви його виконуєте: Це також повідомляє` configure', де знаходити вихідні компілятора; `Configure 'бере каталог з імені файлу, яке використовувалося, щоб викликати його. Але якщо ви хочете бути впевненими, ви можете вказати вихідний каталог за допомогою опції `--srcdir '. Каталог, який ви вказуєте з `--srcdir 'не зобов'язаний бути тим же каталогом, в якому знаходиться` configure'. Тепер, ви можете запускати `make 'в цьому каталозі. Ви не повинні повторювати кроки конфігурації показані вище, при звичайному зміні вихідних файлів. Ви повинні, однак, виконати `configure 'знову, при зміні файлів конфігурації, якщо ваша система не підтримує символічні посилання.
- Кросскомпілятори між машинами з різними форматами плаваючою точки не всі зроблені працюють. GNU CC тепер має емулятор плаваючою точки, з яким вони можуть працювати, але кожне опис цільової машини повинно бути модифіковано, щоб скористатися цією перевагою.
- Кросскомпіляція між машинами з різними розмірами слів кілька проблематична і іноді не працює.
Оскільки GNU CC генерує асемблерний код, ви, ймовірно, потребуєте кроссассемблере, щоб GNU CC міг виконуватися, породжуючи об'єктні файли. Якщо ви хочете лінковані нема на цільовій машині, ви до того ж потребуєте кросслінкере. Ви також маєте потребу в заголовних файлах і бібліотеках, придатних для цільової машини, які ви можете встановити на хост-машині.
кроки Кросскомпіляціі
Компіляція і виконання програм з використанням кросскомпілятора включає кілька кроків:- Запуск кросскомпілятора на хост-машині для породження ассемблерних файлів для цільової машини. Це вимагає заголовних файлів для цільової машини.
- Компіляція файлів, вироблених кросскомпілятором. Ви можете робити це чи ассемблером на цільовій машині, або кроссассемблером на хост-машині.
- Лінковка цих файлів, щоб зробити здійсненний файл. Ви можете робити це також лінкером на цільовій машині, або кросслінкером на хост-машині. Яку б машину ви не використали, ви потребуєте в бібліотеках і в певних стартових файлах (зазвичай `crt. O ') для цільової машини.
конфігурація Кросскомпілятора
Щоб побудувати GNU CC як кросскомпілятор, ви починаєте з виконання `configure '. Використовуйте `--target = мета ', щоб вказати тип цільової машини. Якщо `configure 'виявився нездатним правильно ідентифікувати систему, на якій ви його виконуєте, також вкажіть' --build = строющая '. Наприклад, нижче показано, як конфігурувати кросскомпілятор, який виробляє код для системи HP 68030 з системою BSD, яку `configure 'може правильно ідентифікувати:
Інструментальні Засоби й Бібліотеки для Кросскомпілятора
Якщо у вас є кроссассемблер і кросслінкер, ви повинні їх тепер встановити. Помістіть їх в каталог `/ usr / local / мета / bin '. Є таблиця інструментальних засобів, які ви повинні включити в цей каталог: `as '
Це повинен бути кроссассемблер.
Це повинен бути кросслінкер.
Це повинен бути кроссархіватор: програма, яка може управляти архівними файлами (бібліотеками линкера) в форматі цільової машини.
Це повинна бути програма для створення таблиці ідентифікаторів в архівному файлі. Установка GNU CC буде знаходити ці програми в цьому каталозі і копіювати або компонувати їх у відповідні місця для кросскомпілятора, щоб він знаходив їх пізніше при виконанні.
Найпростіший спосіб забезпечувати ці файли состoіт в тому, щоб побудувати пакет Binutils і GAS. Cконфігуріруйте їх з тими ж самими `--host 'і' --target ', які ви використовуєте для конфігурації GNU CC, потім побудуйте і встановіть їх. Вони встановлюють свої виконувані файли автоматично у відповідний каталог. Але вони не підтримують всі цільові машини, які підтримує GNU CC.
Якщо ви хочете встановити бібліотеки, щоб використовувати з кросскомпілятором, такі, як стандартна бібліотека C, помістіть їх в каталог `/ usr / local / мета / lib '; установка GNU CC копіює всі файли в цьому підкаталозі в відповідне місце, щоб GNU CC міг знаходити їх і лінковані з ними. Нижче показаний приклад копіювання деякої кількості бібліотек з цільової машини:
Точний набір бібліотек, в яких ви потребуєте, і їх розташування на цільовій машині, дуже залежать від операційної системи.
Багато цільові машини вимагають "файли початку" типу `crt0.o 'і` crtn.o', які лінкуются до кожного виконувані файли; вони також повинні поміщатися в `/ usr / local / мета / lib '. Можуть бути кілька варіантів для `crt0.o ', для застосування з профиляции або іншими опціями компіляції. Нижче показаний приклад копіювання цих файлів з цільової машини:
Реальне Побудова Кросскомпілятора
Зараз ви можете продовжити також, як і при побудові компілятора для однієї машини побудовою 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 нічого тут не встановлює.