Это ключевое слово для какого-нибудь компилятора.

многие "ключевые слова" таковыми не являются, например "flash" - обёртка над "__attribute__". "__attribute__" - в ключевые слова добавлен. а вот #define парсер например не смог "развернуть". сталкивался с таким. решается либо настройкой тулчейна, либо прописыванием в эклипсовские пути поиска заголовочников правильных путей.
Да, и о каком компиляторе речь-то?

Вот-вот. Мир компиляторов на gcc не заканчивается. Для того же IAR __flash - ключевое слово, расширение компилятора.

Хороший стиль, все-таки, указать компилятору путь к стандартным заголовочным файлам.
Если используется makefile, сделанный Вами, то все изменения вносите в него (тип контроллера, частота, ключи сборки и др.). Если используете автоматическую генерацию, то ищите в соответствующих настройках среды (в этом случае я не помощник).

поставил 1 пакет - все заработало)))
теперь другой вопрос - вот что поставить на эклипс для работы с арм7 от филипс в частности lpc2478? посоветуйте пожалуйста еще к нему среду прошивальщика
заранее благодарю

__align - ключевое слово компилятора ARM RealView.

Просто в том же SlickEdit я могу свободно добавлять новые ключ. слова типа byte, dword и т.п, что мне будет удобнее.
Странно, что в более навороченном Eclipse такого нет.

ЗЫ: с другой стороны, в SlickEdit (v14) не получилось задать цвет для имён определений #define - то есть само слово define подсвечивается, а имя его определения - нет...

Вот тупое, но действенное решение:
http://www.eclipse.org/forums/index.php?t=...3a65e009734fe93

Насколько я понял после гугления на эту тему: Эклипс не просто пробегается по всем выделенным словам в коде и сверяет со списком ключевых слов. Он делает полноценный C99 парсинг. По этой причине "списка ключевых слов" не может быть в принципе. Как расценивать в таком случае конструкцию:

?
Есть более правильные способы настройки CDTшного парсера, на они требуют знания "потрохов" системы.

Спасибо за развёрнутый совет!
Думаю, это решит часть проблемы

ЗЫ: хотя в "слике" читать текст программы будет проще и удобнее благодаря более гибкой системе цветового кодирования.

Долго не хотел задавать этот вопрос, всё сам пытался найти... Кто-нибудь прикручивал к CDT компилятор M$ VisualC++ ?

Появился вопросец: 

Точно не могу сказать, после чего, но, по-моему, после перехода на EclipseGalileo при старте отладки он(эклипс) стал чего-то ждать. То есть, жмешь дебаг (отладка через мт-линк), при необходимости проходит компиляция, а потом внизу, в строке статуса появляется надпись "Launching <имя проекта>:57%". Вот так висит от полминуты до минуты. Потом начинает обращаться к openOCD или к виндовому GDBserver, заливает код в кристал и начинает дальше трудиться.

На предыдущем эклипсе (Ганимед) такого не замечал. Это только у меня так? и если да, то где и как посмотреть, чего он ждет столько времени?

у меня также. есть еще косяг у галлилео - невсегда кнопки мышкой нажимаются, сие есть видимо глюк ос+java
http://androidteam.ru/faq/eclipse-ubuntu-910-problems.html
все имеется ввиду под Ubuntu 9.10 (Karmic Koala), в масдае все работает

Да, про косячок с кнопками знаю.

ЗЫ. тоже самое относится и к НИОСу9.1 - он ведь тоже на Галилео основан.

Наблюдал аналогичное поведение при запуске компилятора. У меня при исполнении makefile в path дописывается путь к компилятору. Путь берется из переменной окружения. На одной из машин переменная окружения была не прописана, в результате в path добавлялась строка, начинающаяся с \\. Естественно, машина пыталась найти сетевую шару с таким именем.

С кнопками тоже был косяк. Но вчера в системе обновилось куча java-вского софта и этот глюк пропал.

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