gcc: свежак для выни, gcc4.3.0-20071102_bu-cvs20071104 newlib-cvs20071106_gdb-cvs20071105.7z Опции

[klen]

свежая сборка:
binutils 20071104
gcc4.3.0 20071102
newlib
gdb 20071105

размер ~14,3мб
архив формате 7z
оноже самораспакающееся

[Leen]

Развернул архив klena в c:\, получил папку c:\test_arm со всем причетающимся. Внес в системный путь папку c:\test_arm\bin. Добавлял в конец!
Проверяю:
сделал файлик main.c (такой же, как и у Abo);
запустил filemon, с фильтром *gcc*
main.c лежит в D:\temp, там же открыта консоль.
вызываю нечистую силу:

Код

D:\TEMP>arm-elf-gcc main.c
D:\TEMP>

смотрю: появился a.out. Круто...
Смотрю лог:

Код

11:44:36    arm-elf-gcc.exe:2384    DIRECTORY    C:\test_arm\libexec\gcc\arm-elf\4.3.0\    SUCCESS    FileBothDirectoryInformation: cc1.exe    
11:44:36    arm-elf-gcc.exe:2384    DIRECTORY    C:\test_arm\arm-elf\bin\    SUCCESS    FileBothDirectoryInformation: as.exe    
11:44:36    arm-elf-gcc.exe:2384    QUERY INFORMATION    C:\test_arm\libexec\gcc\arm-elf\4.3.0\collect2.exe    SUCCESS    Attributes: A

Далее collect2, роясь у себя в локальной папке (C:\test_arm\libexec\gcc\arm-elf\4.3.0\), безуспешно пытается найти линкер, но я че-то не заметил, когда они нашли друг друга... Потом линкер прилинковывает к временному объектнику разные либы и радостно выкладывает мне a.out. Все...
Притом, повторю, добавлена в путь была только одна директория...
2klen: а зачем в test_arm\arm-elf\bin лежит весь набор гцц для арм-эльф без префиксов? Я посмотрел - они ведь для армов? Это не мусор?

[klen]

а зачем в test_arm\arm-elf\bin лежит весь набор гцц для арм-эльф без префиксов? Я посмотрел - они ведь для армов? Это не мусор?

Не это не мусор. front-end (arm-elf-gcc.exe) для сборки образа использует только тулсами лежащими в /arm-elf/bin библами /arm-elf/lib и хидерами /arm-elf/include. то что лежит в arm-elf/bin есть абсалютно теже файлы чсто в /bin c приефиксом arm-elf-*.exe. Их наличие позволяет их использовать внешним программам(например IDE) не вызывая front-end, для специфических действий.

Структура папок, расположение файлов и путевой механизм в GCC выбраны из сдедющих соображений:
1. Возможность наличия в одной корневой папке ХОТЬ МУЛЬОН!!! компиллеров для разных таргетов, разных версий для одного таргета (в нашем случае ето arm-elf). Ключивое слово - НИКТО НИКОМУ НЕ МЕШАЕТ.
2. При наличии вышеописанной ситуации обеспечена при вызывах соответствующего frontend АВТОМАТИЧЕСКОГО подставления НУЖНЫХ путей библиотек, нужных хидеров и ресурсных файлов. Ключевая фраза - FRONTEND - АВТОМАТИЧЕСКИ за Вас обеспечивает сборку тоько с файлами ресурсов и либами для ВАШЕГО!! таргета.
3. Если вы не хотите по какимто причинам использовать frontend (его по дукоментации часто называют еще и драйвером таргета, потому что он рулит сборкой соответствующими таргету cc1,cc1plus,as,coolect2,ld) Вы можете воспользоватся непосредственно утилитами, НО ТАК КАК ПРИНЯТО УКАЗЫВАТЬ ПУТЬ ТОЛЬКО В /BIN то вам необходимо будет использовать копии файлов размешенных в /bin в которых добавлин в имени префикс, уникальный для каждого таргета. Ключивое сфраза - ВЫ САМИ РЕШАЕТЕ ЧТО ЗА БИБЛЫ И ЛИБЫ И ТД соответствует сборке под Ваш таргет. будьте уверены, Вас попросят указать все пути которые только можно.

Пример, у меня в d:/KGP/ расположено все борохло - тоесть минимально-полные тулчейны (binutils+gcc+libc+gdb) для таргетов avr, arm-elf, arm-elf-cirrus, i686-pc-mingw32,i686-pc-linux с соответствующими наборами либов и хидеров.

Теаперь представте - я еду хрен знает куда(командировка) и там нада подправить ошибки и пререпрошить устройство. Что я делаю - я кладу ВЕСЬ d:/KGP на флешь, прописываю путь к PATH_IN_FLASH/KGP/bin и усиленно РАБОТАЮ А НЕ ТРАХАЮСЬ С ИНСТАЛЯЦИЯМИ В СЛИТЯ ala mastdia win32 !!! ЕСЛИ ТАМ МЕНЯ ПОПРОСЯТ СДЕЛАТЬ РАБОЧЕЕ МЕСТО я кидаю PATH_IN_FLASH/KGP/ с флеша в ЛЮБОЕ место на докальной машине!!! опятьже прописываю путь к bin и все работает. НИКАКОГО ЗАСИРАНИЯ РЕЕСТРА И ТП.

Теперь попробуйте поставить и ЗАСТАВИТ РАБОТАТЬ!!! сразу несколько версий C++Builder, VStudio c разными версиями DDK,DXSDK тд, и для полной картины еще ихже вариации для разработки софта для UMPC. ЖОПА будет всекосмической, это я вам как тот у кого это стоит на ноуте говорю.

вывод: на все вопросы которые былы заданы "A почему так gcc работает а не иначе..." ответ единый - не почему ( ессесено и натурально потому что он так написан) а зачем! затем чтоб был процесс разработки целевого кода а не процесс траха с тем что этот код должно генерить.

Все что знал сказал. как на духу, ниче не утаил.