1. достаточно одного прохода
2. компиллеру для сборки libgcc не требуется newlib
3. newlib при сборке явлет библу libc.a libm.a .... (СТАНДАРТНЫЕ C - библиотеки) , libgcc - это нестандартная C-библиотека а библиотека компиллера с функциональностью поддержки целевой платформы,

пример ARM
реализация оперции ((float)int) или float * float - суть есть libgcc (зависит от набора инструкций)
реализация функций open(..) printf(...) exp() log() - суть libc - СТОАНДАРТ на runtime C, не зависит от целевой платформы, последние две отдеделы в libm - тоже часть стандарта.

есть один момент. для встраиваемых систем для оптимизации часто реализации libc (будьто newlib, glibc, или наверняка можно найти чтото типа ZOPAlibc.. ) имеют порты под конкретный процессор (набор инструкций) и написаны на асме ане на C.

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

Вот и я не могу...

всё.......я сдаюсь.............

где взять правильный скрипт для сборки ARM-тулчейна?!

libgcc.a собирается, но не инсталлируется. перекопировал "куда надо" вручную...
собираю пример от SAM7S64 под GCC, поставляемый со своими либами (в т.ч. libgcc.a) - пример собирается.
удаляю libgcc.a из примера - линковщик не находит перекопированной в "правильное место" либы..
хорошо.. явно задаю путь к каждой либе - либы находится, но сборка прерывается ошибкой.......
сил никаких уже нет..........................

Где взять, не знаю. Но могу описать, как сборка arm-elf-gcc с newlib-ом происходит у меня.

у меня и того проще конфиг GCC

../../src/gcc/configure ../../src/gcc/configure --prefix=/kgp_arm --target=arm-elf --host=i686-pc-mingw32 --build=i686-pc-mingw32 --disable-nls --disable-shared --disable-threads --disable-libssp --disable-libmudflap --disable-libgomp --enable-interwork --enable-multilib --with-newlib --with-headers=../../src/newlib/newlib/libc/include --with-float=soft --enable-languages=c -v

Пытаюсь запустить Эклипс. Пользуюсь документом Using Open Source Tools for AT91SAM7S Cross Development revision C. Дошел до запуска демо-проекта demo_at91sam7_blink_flash. Все проходит как описано за исключением того, что после импортирования проекта происходит его компиляция и во вкладке Problems выдается сообщение о наличии 2 ошибок и 1 предупреждения:
1 ошибка -> error: no memory region specified for loadable section `.eh_frame' line 0 C/C++ Problem
2 ошибка -> make: *** [main.out] Error 1 line 0 C/C++ Problem

предупреждение -> Error launching external scanner info generator (gcc -E -P -v -dD C:/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c)

Помогите разобраться! В чем проблема?

Сообщение отредактировал 011119xx - Feb 28 2010, 14:35

Проект не плюсовый? Вываливай...

(это в файле .cmd - скрипт линкера)

Когда дойдёте до запуска программатора, поделитесь исправленными файлами .cfg от opencd.

Сообщение отредактировал Genadi Zawidowski - Feb 28 2010, 19:51

Извините, но мне не понятно что делать. То что это надо добавить в файл .cmd понятно, а куда конкретно - нет.

Куда-нибудь в конец, перед последней скобкой:

Что касается warning-а, то это Project - Options - C/C++ Build - Discovery options, и там либо снять птичку "Automate discovery...", либо выбрать "GCC per project scanner info profile" и заменить в строке "compiler invocation command" "gcc" на "arm-gcc" или что там у вас.

Спасибо. Это помогло.

Всё.... Имел я ввиду этот Eclipse CDT для ARM вместе с YAGARTO, Cygwin и иже с ними. Столько времени потратил только для того чтобы убедиться что другие были правы в том что не нужно связываться. Из своих наблюдений смело могу заключить что вся эта конструкция нопоминает оную из кубиков разного размера и неправильной формы, благодаря чему получается что любая посторойка обречена на развал, а если и простоит какое-то время то развалиться при следующей попытке использования. Отсюда же следует маловероятность повторить то что уже сделано (и скорее всего развалилось).
Чем сложнее задумання конструкция, тем, в корне убическом, меньше шансов на успех. Потому на интернете и нет упоминаний о проектах отличных от Demo примеров.
Дальше примеров дела идут, видимо, только в исключительных случаях.
Имеете желание улететь с работы – Eclipse вам в руки.
Это же надо такое предложить:
Сначала поучите как составить makefile, потом linker script, потом попудрите мозги над опциями компилятора и вообще над тем как его прикрутить к Eclipse. Прикрутили ? Замечательно – теперь ещё библиотеки надо. А какие? А кто его знает – надо ещё несколько дней потрахтить чтобы выяснить.
Ещё каки-то файлы конфигураций по любому поводу, по разным правилам.
Для одного дебаггера один хаос, для другого другой.
И ещё интересно – инженер поддержки из NXP, котрый несколько часов ведёт занятия и лабораторную работу по NXP Expresso ( Eclipse с Code Red) , при вопросе - “ Ну, хорошо, с вашими Evaluation PCBs дебагить можно. А как симулировать? “ , бодро, со знанием дела отвечает –“ Хороший Вопрос! Не могу на него ответить, но узнаю обязательно!”
Так как тогда продвигаться дальше, если не-у-кого получить быстрый и вразумительный ответ?
И так неделями – и на работе и дома. Так и не вник.

Как говорится - плохому танцору... Делать что-то не читая документации - прямой путь к вашему результату.

P.S. Если вы начинаете общение на форуме с такого "вброса говна на вентилятор" - маловероятно, что вы что-то серьезное представляете из себя как специалист и ваш результат закономерен.

мдя, однако мнение.
для тех кто еще сомневается - повторю слова из изветной рекламмы "- USTAL, ты так и не научился их готовить..."

YAGARTO + Cygwin - это же надо было додуматься!
А вот мне Eclipse нравится всё больше. Уже много проектов в ней собрал и много народу на неё подсадил, все довольны. Наверное я мазохист

+1:)

ЗЫ. Сдаётся мне, что этот CodeRed только сбивает с толку людей. Потому что создаёт обманчивое впечатление, что есть готовое решение типа IAR, а на самом деле разбираться всё равно во всём приходится самому.
Честно говоря, не понимаю, кто покупает это.