Может быть кто уже пробавал пристыкнуть IDE оболочку под кросскомпилятор Sourcery CodeBench Lite
IA32 GNU/Linux чтобы компилировать под ARM. Если да то подскажите что можно использовать в качестве IDE под Линукс.
Заранее спасибо с уважением Алексей.

Eclipse например

Мне кажется, что можно прикрутить оболочку Code::Blocks.

Что касается меня лично, то я тоже в свое время, когда перелез с Виндовс на Линукс, тоже страдал такой фигней -- "вынь, да положь мне на тарелочку оболочку!" Ну, привык я работать в Виндовсе, и на мир смотрел через призму а-ля-Виндовс. Я тоже искал оболочку, которая меня бы устроила. Не нашел.

Но потом, подначитавшись умных книжек (Э.Реймонд "Искусство программирования для UNIX", Б.Керниган и Р.Пайк "Программное окружение UNIX", Уильямс Ричард Стивенс "UNIX. Профессиональное программирование", Н.Мэтью и Р. Стоунс "Основы программирования в Linux" и др.), я кое- что понял. Я понял, что я неправильно понимаю дух (природу) Линукса. Я пытаюсь требовать от него Вендового поведения или Вендовых подходов. Виндовс и Линукс -- это две разные технологии, хотя у них есть много чего схожего.

Феномен IDE в Линуксе -- это не то, чтобы нечто второстепенное,... скорее -- не столь важное, как это есть в Виндовсе. Виндовс идет по пути: "всё, что можно, -- всё вложить в (одну) программу. Всю функциональность закатать по максимуму. Надо-не надо -- не важно! Важно, чтобы программа была самодостаточной жирной единицей, независимой от других программ." Такой подход становится понятен, когда начинаешь задумываться о природе Виндовс. Виндовс и вся ее экосистема задумана и живет с целью ПОЛУЧЕНИЯ ПРИБЫЛИ. И если ты (абстрактно, не персонально к топикстартеру) -- программист, то твоя задача -- писать и продавать свои проги. Следовательно, тебе будет очень не уютно, когда твоя прога должна будет использовать какую-то стороннюю функциональность. Поэтому ты будешь вынужден напихать в свою прогу по максимуму всё. Всё что надо и не надо. В результате мы наблюдаем появление таки монстров как Atmel Studio. Жуть!

"А шо делать?" -- Рабинович. (с) фраза из анекдота

Линукс же идет несколько иным путем. Парадигма Линукса состоит в том, что имеется система, состоящая из ядра и множества утилит и программ. Утилиты и программы обладают ограниченной функциональностью, но при этом легко стыкуются друг с другом. Таким образом, обладая набором тщательно отлаженных качественных программ мы с помощью "клея" (скриптов и каналов) можем создавать из них любую, нужную нам, функциональность. Поскольку небольшие программы и утилиты легко писать и отлаживать, то это гарантирует высокую их надежность. А если система состоит из надежных проверенных "кирпичей", то и вся стена будет так же надежна. Остается только добавить, что если даже вдруг случайно где-то встретится трухлявый "кирпич", то, поскольку, никто секретов из исходников не делает, этот кирпич тут же будет замечен и исправлен. Разнообразие "кирпичей" и их способов соединения порождает бесконечное число вариантов -- стен, строений, домов и т.д. Имея набор акварельных красок, можно нарисовать ЛЮБУЮ картину. Виндовс же вместо красок предлагает уже готовый и сильно фиксированный эстамп. Что называется -- почувствуйте разницу.

Я Вас не убеждаю, что одна одна операционная система лучше, чем другая. (В конце концов, каждый сам делает свой выбор!) Я лишь говорю о том, что не все подходы , которые приняты в Виндовсе, нужно переносить в Линукс. Они, конечно, наверняка будут работать, но это не совсем верное решение -- переносить один к одному методы работы при фундаментальной смене технологий. Намаетесь, потому как природа операционной системы -- другая, здесь другие подходы. Понятно, что используя родные подходы для системы, можно добиться значительно больших результатов, чем при использовании "иностранных".

Теперь, я хотел бы вернуться к IDE. Я перебрал несколько IDE, и остановился на том, что наиболее лучим вариантом для меня буде не готовая IDE, а то, что я сам создам своими руками из готовых кирпичей. Мои кирпичи -- это окна Наутилуса и Гном-терминала. Это несколько рабочих столов, это могут быть чистые консоли (Ctrl-Alt-F1? Ctrl-Alt-F2, ...), в том числе и удаленные консоли на других компах. Это мои Мейк-файлы, это компиляторы, отладчики, утилиты и другие программы, которые я вызываю из Мейк-файла. Ну и другие мелочи, которые я не хотел бы сейчас перечислять. Ни один IDE монолитный не способен на такую гибкость!

Я согласен, что по началу чувствуешь себя несколько дискомфортно, из-за того, что оно (аналог IDE) не существует в виде единого монолита, а как-то все разрозенно и раскидано. "Где, что и как потом собирать?" -- это надуманный вопрос. Это влияние Виндовса на наши умы (по крайней мере -- на мой). После некоторого времени работы с таким виртуальным IDE, убеждаешься не только в его работоспособности и возможности его принципиально запускаться каждый раз, но и в его удобстве и в своем всемогуществе УПРАВЛЯТЬ системой. (Зря что-ли пошла поговорка: кто кого имеет -- ты систему, или она тебя.)

Поэтому, я хотел бы обратить Ваше внимание на вот какой момент. IDE в Линуксе -- это, конечно, хорошо. Но если Вы нацеливаетесь на серьезную работу, то Вам по-любому придется копать глубоко Линуксовые технологии, и вот тогда... тогда Вам откроются секреты, почему в Линуксе с IDE "как-то не очень". Я не знаю, сколько времени Вы уже пользуете Линукс, но я могу сказать, что сменить образ жизни с Вендового на Линуксовый -- это достаточно ощутимая работа ума. Говорить, что легко перскочил с Венды На Линукс -- это лукавство. Ну, либо человек просто идет по верхам, и глубоко не копает. Чудес не бывает, но есть определенный объем умственной работы, который нужно совершить, и есть ограничение -- 24 часа в сутки на все про все!

Зайдите ко мне в блог, у меня там есть несколько публикаций для начинающих эмбеддеров, где я расписываю как работать в Линуксе, как создавать свою среду для работы с микроконтроллерами.

Не поймите меня меня неправильно -- я не против использования IDE в Линуксе. Я лишь попытался обрисовать общую картину, расширить, так сказать, мир, чтобы вы не замыкались на IDE, а могли видеть дальше и больше, и знать, что вообще происходит. Дополнительные знания дают правильную ориентацию. А правильная ориентация приведет к правильному выбору инструментария для достижению ваших целей.

Еще раз мои извинения, за "много слов". Ну не умею я говорить кратко о сложных технологиях.

Ситуёвина такая.
1. Code::Blocks хорош, но из-за небольшой кривизны сабжевого GDB плагин отладчика там не работает
2. Eclipse хорош, но CDT плагин из-под нее радует сюрпризами. В общем, эта часть там глючная. В связи с этим создается проект , основанный только на Makefile. Зато отладка работает.
Собсна, что человеку надо: редактор с автозаполнением, да ctags...

Преогромнейшее всем спасибо за ответы.
Логика zhevakа мне понятно. Теперь вкратце о себе. Я некий такой нулик без хвостика как в Линуксе так и Виндовз. Поэтому будучи пластичным материалом из меня можно сделать что угодно. Поэтому тезисы мне ясны, и скорее всего перед прикручиванием IDE наверное попробую без него. Я только начал изучать Линукс сразу на своей задаче. В блог схожу и почитаю и приму обязательно грамотные мысли мудрого опытного человека. Я прекрасно понимаю при переходе с одного на другое возникает некое противление. Ну как всё неудобно, ну неужели нельзя было сделать как ...А потом спустя какое-то время уже работаю начинаешь понимать да нет не всё так просто. Поэтому проработав более 10 лет преподавателем в телекоме и преподавая технику определённого производителя когда встречаешься с теми кто работал с другими технологиями и аппартными исполнениями очень хорошо понимаю, что мне докладывают. Вся информация принята. Я в себе это чувство научился притуплять (поспешные выводы) как у Вас всё не правильно. Так что в Линукс. Буду постигать.
С уважением Алексей.

Если у Вас действительно мало опыта, то я бы посоветовал готовую настроенную IDE, если есть такой вариант. В новой области хватает подводных камней, поэтому настройку средств разработки полезно отложить на более позднее время, если есть возможность. Настройка среды для сборки программы и IDE при отсутствии опыта может занять больше недели. Такие усилия оправданы для масштабных проектов, когда повышение продуктивности от хорошо настроенной и удобной среды перекрывает затраты на настройку.

Я остановился на make + qtcreator + openocd.

vim + ctags + cscope

А я поковырялся в QtCreator - так и не смог завести под ним gdb + openocd, поэтому остановился на Code::Blocks

А с этого момента - поподробнее плз
GDB от codesourcery запустился или нет?

Прошу прощения, я использовал самосборный тулчейн.

Таки придется сделать то же самое. C::B гораздо удобнее эклипса.

Вопрос по Code::Blocks: как там обстоят дела с навигацией по коду (к примеру, прыгнуть на определение переменной, увидеть список функций, вызывающих подсвеченную и т.д.) ?
Вопрос не праздный, так как я давно использую Source Insight и сильно подсел на эти фишки. К сожалению, Source Insight при анализе кода не разворачивает макросы (в частности, protothreads), поэтому в некоторых участках кода навигация не работает. Кроме того, он сваливает в одну кучу одноименные переменные и функции, даже если они в разных файлах и объявлены как static. Для пробы установил Eclipse: там нет таких проблем, но его монструозность напрягает.

Вообще-то вышел RC недавно 12-й версии, но под вынь, пробовать не особо когда.
Эклипс с этой точки зрения хорош, но там даже не монстр-сть - там некоторые вещи казалось бы настроил и вперед - нет, напрягают. По мелочам, но из этих мелочей - нивазможна просто.
И чтобы работал разворот макросов - нужно дефайнить внешние макросы по два раза и builtins
В C::B 10 это все не работает, как хотелось бы.

Не в тему, но вы наверняка знаете о understand c++. У нас в проектах используется изощренная система макросов и SI действительно пасует перед такими задачами. В таких случаях understand просто вне конкуренции. У нас автоматом генерятся файлы проектов с помощью make файла

Идея простая - в папке RELSDIRFULL собирается список файлов проекта, добавляются пути с инклюдами includepathlist.txt и значения дефайнов cdefineslist.txt. Создается база данных проекта и запускается на анализ. Understand анализирует очень акуратно, у нас в некоторых проектах почти все функции определяются через макросы. Навигация в SI в этом случае не работает. С Understand все работает замечательно.

С "удобнее" не согласен. С "гораздо" - категорически не согласен
Что касается вашей проблемы - боюсь, проблема не в тулчейне, а как раз в C::B. Ну не заточен он под embedded, и затачиваться не собирается. Я лично вскоре после того, как понял, что отладка embedded-проектов в C::B невозможна, сполз с него на эклипсу, и ничуть не жалею. (Хотя может быть с тех пор что-то и поменялось, я не следил.)

А вы расслабьтесь Компьютеры пятилетней давности легко тянут эклипсу. Ну запускается на несколько секунд дольше. Так это ж ерунда
Зато умеет практически всё, а если чего не умеет, то для этого обязательно есть плагин

Угумс.
Вот туды бы они питон вставили - оченно пошел бы. В написании визардов черт ногу сломит. И эта сцинтилла, блин, недоделанная...

В курсе, что намедни новая (12.11) версия C::B вышла?
http://www.codeblocks.org/home

Там написано, что под убунтой 12.04+ не работает

Netbeans посмотрите. Тулчейн прописываете и вперед.
Собираем проекты под ARM. GDB не прикручивали - printf наше все
Хотя в интернетах пишут, что gdb прикручивается на раз-два начиная с nb6.7.

Кстати
Netbeans vs Eclipse?
Кто может сравнительный приговор вынести?

В эмбеде вроде как больше эклипс принято.
А нетбинс - он как бы больше в вебе.. Я пробовал, сходу не получилось, забил, потом потерял.. Потом с::В..
Теперь VS - худший вариант из всех возможных.

Очень даже в тему. Я его пробовал когда-то, но почему-то отсеял. Сейчас попробовал снова: вещь! Спасибо за наводку.

Может пропустил но тем не менее.
Под eclipse есть плагин http://sourceforge.net/projects/gnuarmeclipse/
Он как раз и поддерживает codesourcery

Сам нахожусь в процессе изучения тулов на ARM, набрёл на такую ссылку - возможно, будет полезна
http://robocraft.ru/blog/ARM/653.html

Eclipse + CDT + GDB Hardware Debugging + st-util + git
очень даже удобная и легко кастомизированная среда разработки