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

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

Когда-то у нас c тобой был разговор о toolchain под Windows для линуксовых приложений. Забыть? Или каке-то шансы есть?
P.S.
Для желающих объяснить неправильность подхода к делу, предистория здесь:
http://electronix.ru/forum/index.php?showt...lchain&st=0

"простенькие консольные приложение" это что? в смысле какие либы будут использоватся?
вообщето сама постановка задачи видется мне порографическим извращением но я очеть не люблю когда мне говорят что я хочу чтото не правильное и объясняют что правильно нада хотеть, поэтому попробую собрать кросс win32->linux/elf binutils gcc.
В принципе либы можно будет выдрать из линуха, так что даже интересно чтонить получится или нет.

Это не принципиально, поскольку либы-то собственно от нативного линукса.

Я тоже не радуюсь

Порадовал!
P.S.
Если ты помнишь наши разговоры было еще одно условие - сие должно быть выложено в интернете, но с этим думаю проблем не будет

2 zltigo
А может, всё-таки машину реальную или виртуальную с линуксом, а к ней икс-сервер на винду? или вместо полного икс-сервера такую шнягу?
http://www.enginsite.com/GCC-Builder.htm

Дык...это... распинался (ну может не совсем открытвм текстом) уже о причинах, почему в уловиях в которые меня поставили идеальным будет имеено банальная сборка линуксового приложения под голой виндой. Какой компромис пока по взаимному полумолчаливому согласию используется я описывал.

2_злтига

бинутилс собрался, гсс не собрался - нужны хидеры, буду пробывать выдираить из линуха. посмотрим че получится.

НО!!!! на асме уже можно писать!! думаю Вас это не испугает

Испугает . А заказчика повергнет в шок....

заказчик нежный у Вас, наверноденег у него много... короший заказчик однако

2 klen:
Здравствуйте,
прошу помощи, ибо сломал сегодня всю голову:
загрузил Вашу сборку kgp-arm-gcc4.3.20071005-bu-cvs20071007-newlib-cvs20071008.-gdb-cvs20070911.exe
под Win и попытался скомпилировать программу:

int main(void)
{
while(1);
}


вызываю
>gcc main.c
из командной строки, а в ответ :
>gcc.exe main.c
gcc.exe: CreateProcess: No such file or directory

при этом путь к экзекшникам есть.
что посоветуете?

Косяк.. это потому что фронтэнд - arm-elf-gcc.exe не находит сам компилятор сс1 который должен лежать libexec/gcc/arm-elf/4.3.0/cc1.exe если его там нет то касяк при распаковке архива. Также должены быть arm-elf/bin/as.exe arm-elf/bin/ld.exe. Посмотрите Filemon куда стучится arm-elf-gcc.exe, если их ищет и ненаходит, а они есть где я указал то мой касяк, буду разбираться.

странно, вроде все работает. я разных машинках тестирую

сс1.exe лежит в каталоге d:\embedded\gcc\libexec\gcc\arm-elf\4.3.0;
вот фрагмент протокола доступа к файлам:


мне показалось странным что в каталоге D:\EMBEDDED\GCC\libexec\gcc ищется и сс1 и сс1.exe
а в каталоге D:\EMBEDDED\GCC\libexec\gcc\arm-elf\4.3.0 только сс1.

проложил путь до каталога D:\EMBEDDED\GCC\arm-elf\bin, скопировал туда cc1.exe из
D:\EMBEDDED\GCC\libexec\gcc\arm-elf\4.3.0 и попробовал "gcc main.c" скомпилировало, слинковало получился a.out.
вызвал "arm-elf-gcc main.c" - тоже сработало.

я так думаю, что всетаки правильнее работать через arm-elf-gcc, ведь если еще на этой же системе стоит другой кросскомпилятор, то и вызов будет другой?

Вообще-то правильно работать ВСЕГДА через arm-elf-gcc для КРОСС компиляторов.
Потому как gcc это НАТИВНЫЙ компилятор.
У кросс компилятора в папке libexec могут быть файлы для ТАРГЕТ. Которые естественно могут не совпадать с ХОСТ у кросс компилятора.

я даже и предположить не мог ..
я что? просто так собираю пакет??? нет такм никакого gcc.exe
Все кросс компиллеры имеют префикс для того чтоб их можно было иметь в одной корневой директории


жесть! я ведь по настоящему испугалсИ

Есть к Вам вопрос. Не могли бы Вы приделать к армовскому линкеру при генерации .elf-файла с директивой -r (т.е. с релокациями) непосредственную обработку всех релокаций, которые возможно обработать при линковке (например BL на процедуру в одной секции?). Т.е. чтобы на выходе в .elf-файле был минимально необходимый набор релокаций?

ну файл gcc.exe там всетаки есть в каталоге D:\EMBEDDED\GCC\arm-elf\bin.

а по существу, без стеба, в чем я не прав, почему не работает как положено?
куда в структуре каталогов должен быть прописан путь?

да ни кто не стебется.
компиллер собран таким образом что призапуске frontend (arm-elf-gcc) сначала вызывается /libexec/gcc//arm-elf/4.3.0/cc1.exe на выходе асмовские файлы, далее он пихает их ассемблеру /arm-elf/bin/as.exe
на выходе объектники котрые он пихает линкеру /arm-elf/bin/ld.exe на выходе образ, посде чего arm-elf-gcc завершает работу.

Правильное использование - только вызывами /bin/arm-elf-gcc.exe
Я не понимаю че Вас не устраивает?

Прошу объяснить, почему frontend (arm-elf-gcc) не запускает cc1.exe из /libexec/gcc/arm-elf/4.3.0/cc1.exe, если путь проложен только до каталога в котором лежит arm-elf-gcc. Однако cc1.exe запускается, если проложить путь и к тому каталогу в котором он лежит. Может у меня какая нибудь переменная среды не установлена?

Это чето какойто глюк. Я немгу определить что происходить. Вы директории ручками не перемешивали?
структуру директорий в корневой папке (у Вас это D:\EMBEDDED\GCC) жеско заданная. Все должно начинать работать при прописывании в PATH D:\EMBEDDED\GCC\bin и категорически!! больше ничего.

Поаробуйте поместить весе в папку вершнего уровня. например D:\GCC и посмотрите че выйдет.
У когонить еще есть такое безобразие?

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

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

Далее collect2, роясь у себя в локальной папке (C:\test_arm\libexec\gcc\arm-elf\4.3.0\), безуспешно пытается найти линкер, но я че-то не заметил, когда они нашли друг друга... Потом линкер прилинковывает к временному объектнику разные либы и радостно выкладывает мне a.out. Все...
Притом, повторю, добавлена в путь была только одна директория...
2klen: а зачем в 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 работает а не иначе..." ответ единый - не почему ( ессесено и натурально потому что он так написан) а зачем! затем чтоб был процесс разработки целевого кода а не процесс траха с тем что этот код должно генерить.

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

Гы Заметно. Спасибо.
судя по конфигу, распихиваете и переименуете Вы все хозяйство ручками? А то program-prefix'ов в упор не видю в configured with для gcc. Правильно? Или есть еще какие-то методы указать мейку, куда пихать при инсталле, и как переименовывать, чтобы получить две копии с разными именами и путями?
Библиотечка msys.dll для чего нужна? Вроде, гцц -в и без нее отзывается... И даже компилит.

configure --prefix=XXX указывает куда ставить относительно рутовой директории, я указываю --prefix= что соответствует установки всего в рутувую, если не указать вообще то по умолчанию будет тоже что и --prefix=/local, нафига мне еще корень установки?? тогда прийдется еще и в /local/bin путь указывать. Это все дело сборщика, как он потом хочет тулсы использовать.


это потому что я докладываю в пакет make,sh,rm - этого достаточно чтоб собирать проекты основанные на make

2 klen
Продолжаем разговор.

Провел с утра такой эксперимент.
На своем компе под вистой распаковал kgp-arm-gcc4.3.20071005-bu-cvs20071007-newlib-cvs20071008.-gdb-cvs20070911.exe в каталог C:\GCC.
Проверил работоспособность описанным способом (c:\gcc\bin\arm-elf-gcc main.c)- в ответ:

D:\qq>c:\gcc\bin\arm-elf-gcc main.c
arm-elf-gcc: CreateProcess: No such file or directory.


Проделал в точности те же операции на виртуальной машине с ВИН_ХР СП2.
Результат - все работает как надо, а.out присутствует.

Резюме - "что то не так в консерватории".
Либо в висте по сравнению с ХР что то поменялось, либо в GCC что то не так.

Отказываться от висты в связи с вышеозначенным, что то не хочется, что же делать?
Для возможного анализа прилагаю протокол обращений к файловой системе для висты в cvs фрмате.
(удобно смотреть экселом)
меня немного удивило что там присутствует обращение к файлу D:\KGP\lib\gcc\arm-elf\specs
ведь каталога d:\kgp у меня отродясь не было .

Кстати, еще вопрос, для чего нужны f951.exe и collect2.exe из libexec\gcc\arm-elf\4.3.0

>>Резюме - "что то не так в консерватории".
>>Либо в висте по сравнению с ХР что то поменялось, либо в GCC что то не так.
Ниче в висте не поменялось!! Винда как была гавном, так и остается им. Разве что прогрессирует:
1. Она таки находит сс1.exe
2. Но почемуто принимает решение что это не бинарник а директория - и естественно его не пытается запускать. На это и рушается что не может процесс cc1.exe запустить.
3. Что это и как с этим боротся? пока понятия не имею, Вы первый кто подянл вопрос. У меня висты нет потестить. Скорее всего глюки выни.


>>Кстати, еще вопрос, для чего нужны f951.exe и collect2.exe из libexec\gcc\arm-elf\4.3.0
f195 - нативный компиллер фортрана, я им математические модули компилю для арма, ну там если посчитать че нужно. collect2 -утилита использующаяся при линковке.

У меня. Такме же глюки наблюдаються в Vista с winARM 20060606. Для того чтобы исчез один из "CreateProcess: No such file or directory" ришлось cc1 в C:\winARM\bin\ класть. Проверялось на 2-х машинах.
В XP все нормально. Вроде как в wine пускал тоже нормально было. Правда, не помню точно.

вот и я про тоже. на всх ОС работает, а под вистой нет. . для справки. сам gcc использует только ANSI C стандартные библиотечные вызовы, в нашем случае имеется ввиду файловый ввод-вывод. Поэтому всетаки мне ближе идее что в висте чето не так работает.

Положить сс1 в /bin конечно можно и даже наверно будет работать (хотя вроде не должно, нада исходники посмотреть). Но тогда нелзя в одной рутовой директори держать разные версии компиллера - это нехорошо.

Я скоро буду собирать свежак и могу посмотеть в чем может быть касяк и попробую переделать. Если ктото потестирует я этим займусь. У меня висты не будеть.

Ну я могу протестировать.
Завтра с утреца твою сборку посмотрю под Vista. Помойму у тебя с 20060606 какие-то различия в именах файлов и придеться makefile править. А он корявый (от Embedded Artist).
А так собирай я протестирую.

Готов со всей душой помочь общему делу!

Оказывается с подобным поведением GCC под вистой давно известно, говорят что дело в MinGW а совсем не в висте.

http://gcc.gnu.org/ml/gcc/2007-05/msg00219.html