Итак. Оно собралось. Даже компилирует. Пока обнаружил один косяк - gcc не подлинковывает автоматом crt430x261x.o. Для 241х все нормально. Ошибку исправил, пошлю им патч - судя по рассылке там началась некоторая активность. Не нравится, что собирается оно из цыгвина. Если кто имеет опыт легкого перевода сборки из-под цыгвина на MinGW - буду благодарен. Еще не понравилось - все файлы исходников и документации в сборке под винду имеют линуксовые переводы строк. Неплохо бы их конвертить при генерации инсталятора.
-------------------------------------------------
Инструкция, если кому-то захочется собрать тоже.

1) Ставим cygwin (желательно в c:\cygwin, иначе придется править файлы .nsi)
2) Запускаем setup от cygwin, проверяем, что стоят
cvs,
binutils,
gcc,
libintl2 (в ней живет cygintl-2.dll)
diffutils
patch
!!!! Проверяем, что не стоит python(чтобы вызывался python из виндовса, в котором есть py2exe. py2exe под цыгвин не бывает)
3) Ставим под винду:
Python: http://www.python.org/download/
py2exe: http://sourceforge.net/project/py2exe/
pywin32: http://sourceforge.net/projects/pywin32/
NSIS: http://puzzle.dl.sourceforge.net/sourcefor...-2.37-setup.exe
4) Вытягиваем исходники из cvs:
mkdir mspgcc/sf
cd mspgcc/sf

export CVSROOT=:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc
export CVS_RSH=ssh
cvs login (на запрос пароля жмем Enter)
cvs checkout .
5) создаем в цыгвине директорию /opt/mspgcc (не знаю зачем, но так написано в их инструкции)
mkdir /opt/mspgcc
6) (этот шаг пропустить, патчи уже внесены в cvs репозиторий mspgcc) копируем патчи в ~/mspgcc/sf/packages/patches отсюда: http://homepages.inf.ed.ac.uk/mbarnes/msp_patch/
makefile сохраняем в ~/mspgcc/sf/packages
7) скачиваем с сайта и кладем в ~/mspgcc/sf/packaging файлы, которые пока не строятся автоматически:
mspgcc-faq.pdf, mspgcc-manual.pdf.
msp430-gdbproxy.exe
msp430.dll
8) создаем директории:
make folders
9) у меня wget отказался скачивать исходники (я за проксей), поэтому исходники (binutils-2.17.tar.bz2, gcc-core-3.2.3.tar.bz2, gcc-g++-3.2.3.tar.bz2) я скачал с http://ftp.gnu.org/gnu в ~/mspgcc/packages/archives вручную оперой.
gdb-6.0.tar.gz2 лежит на ftp://ftp.sources.redhat.com/pub/gdb/old-releases
10) Если python версии 2.5 или выше, то:
- удаляем в ~/mspgcc/sf/packages/mspgcc-full-install.nsi ссылки на zlib.py
- заменяем ссылки:
python24.dll -> python25.dll (или на соответствующий версии питона)
PyWinTypes24.dll -> PyWinTypes25.dll ( --//-- )
Если cygwin ставили не в c:\cygwin, то правим ссылки на него в mspgcc-base.nsh, mspgcc-full-install.nsi
11) идем в ~/mspgcc/packages и запускаем строительство:
make build-installer

а проблема в чем?
все также

Ну например вот:

Решил повторить этот подвиг.
Вопрос по п.2

Где проверяем и как?
Сорри за тупые вопросы, до меня просто как до жирафа обычно доходит...
А поколупать хочется...

При запуске setup он предложит выбрать устанавливаемые пакеты. Вот там и убедиться, что названные пакеты установлены. Этот сетап можно запускать сколько угодно раз, добавляя/убирая пакеты.

Вообще, эта инструкция несколько устарела. Сейчас mspgcc собирается не под cygwin, а под msys. Поэтому технология несколько изменилась.
1) Ставите msys, mingw32, python
2) cvs -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc login
3) в TortoiseCVS проходит cvs -z3 -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc co .
3a) с командной строки приходится вытягивать каждый модуль отдельно:

4) в packaging добавляю в makefile в самое начало строчки
5) make folders
6) в создавшуюся packaging/archives копируем binutils-2.18.tar.bz2, gcc-core-3.2.3.tar.bz2, gcc-g++-3.2.3.tar.bz2, gdb-6.8.tar.bz2
7) make build
в packaging/build/installed получается собранный пакет, но без инсталятора. Его можно копировать в нужное место и прописывать в path путь к его папке bin. Или не копировать.
Инсталятор пока не освоил - не смог с налета собрать документацию.

Откуда такая информация?
Официальная инструкция, датированная февралём 2009, об этом умалчивает. Там правда, предлагается всё скачать с редхэта и гну.орг, может, это оно и есть, я пока в таких тонкостях не ориентируюсь...

Вот что получилось:

У меня подозрение, что сисадмин порты режет...
Насколько я понимаю, нужно открыть порт 2401?
########
Перетёр с админом, картинка поменялась:


на -z3 такая же реакция.

Ладно, попробую ещё дома. Там сам себе одмин

Из дистрибутива пропал cygwin.dll, зато появился msys-1.0.dll. В патч binutils для 430x включена правка objdump именно для msys. В глобальном makefile bp packaging есть строки "if MSYSCON". Да и сам я его так собираю.
А вы не через проксю ходите случайно? У меня аналогичное поведение дома. Через проксю cvs в режиме pserver не работает. Точнее ходят слухи, что работает cvs -d:pserver;proxy=proxyhost;proxyport=8080:username@somedomain.tld: но мне из дома так и не удалось.

Да, через корпоративную проксю
Ну да бог с ним. Дома проверю. Хотя и там наверняка что-нето прикручено (JDSL™)

Ещё вот давно такой вопрос мучает: почему mspgcc "засохло" на версии GCc 3.4 ?
Почему AVR-GCC (и WinAVR) включен в основной состав и шагает в ногу с основным проектом?
Что за дискриминация?

оно не само шагает, это мы c Вами его и шагаем , если mspgcc "никто его шагать" нехочет то наверно он не сильно нужен...

И с каждым обновлением avr-gcc появляются стоны "проект стал больше". Где-то в рассылке по mspgcc проскакивало обсуждение, резюме было примерно таким - с точки зрения компактности кода gcc 3.x лучше, а поскольку в embedded-устройствах память - весьма ценный ресурс, то переход на 4.x был признан непреспективным.

Как и предполагалось, дома всё прошло на ура.
Черепашка с точкой вместо имени модуля выкачала из репозитория всё что только можно за минуту.

Ладно, идём далее.
Выдержка из официальной инструкции:

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

Получаете построенный инструмент в packaging/build/installed. Поддержка 430Х пока привязана к binutils 2.18, впрочем он должен все необходимое выкачать сам.

Не находит. При просмотре по веб-интерфейсу не видно такого пакета.

То ли я ошибся, то ли что-то изменилось, но для строительства libmspgcc используется модуль jtag:
cvs -z3 -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc co jtag
Но он вам скорее всего не нужен - это работа со старыми кристаллами, поддержки новых в обозримом будущем не будет.

спасибо, попробую подсунуть модуль jtag, в логе на него были указания.

Компилятор собрал. Собралось далеко не все. Времени нет разбираться на чем рухнула сборка. Очень расстроился, что в заголовочных файлах практически вся периферия для семейства 54xx не доступна (закомментирована).