У Sourcery make называется cs-make. Исправьте в настройках проекта.
Кстати, в репозитории есть более свежие примеры.

Получилось примерно следущее в CoIDE
GCC HOME: C:\Program Files (x86)\GNU Tools ARM Embedded\4.8 2014q1\bin
compile:
[mkdir] Created dir: C:\CooCox\CoIDE\workspace\start_this\start_this\Debug\bin
[mkdir] Created dir: C:\CooCox\CoIDE\workspace\start_this\start_this\Debug\obj
[cc] 200
[cc] 9 total files to be compiled.
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -Wall -ffunction-sections -g -O0 -c -DSTM32F407VG -DSTM32F4XX -DSUPPORT_CPLUSPLUS -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ -IC:\CooCox\CoIDE\workspace\start_this -IC:\CooCox\CoIDE\workspace\start_this\cmsis_boot -IC:\CooCox\CoIDE\workspace -IC:\CooCox\CoIDE C:\CooCox\CoIDE\workspace\start_this\OS_Kernel.cpp C:\CooCox\CoIDE\workspace\start_this\startup-stm32f4xx.c C:\CooCox\CoIDE\workspace\start_this\sys.c C:\CooCox\CoIDE\workspace\start_this\main.cpp C:\CooCox\CoIDE\workspace\start_this\OS_Target_asm.S C:\CooCox\CoIDE\workspace\start_this\OS_Services.cpp C:\CooCox\CoIDE\workspace\start_this\usrlib.cpp C:\CooCox\CoIDE\workspace\start_this\sysinit.cpp C:\CooCox\CoIDE\workspace\start_this\OS_Target_cpp.cpp
[cc] Starting link
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -g -Wl,-Map=start_this.map -O0 -Wl,--gc-sections -LC:\CooCox\CoIDE\configuration\ProgramData\start_this -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\start_this/arm-gcc-link.ld -g -o start_this.elf ..\obj\OS_Kernel.o ..\obj\startup-stm32f4xx.o ..\obj\sys.o ..\obj\main.o ..\obj\OS_Target_asm.o ..\obj\OS_Services.o ..\obj\usrlib.o ..\obj\sysinit.o ..\obj\OS_Target_cpp.o -lm -lgcc -lc -lrdimon -lstdc++
[cc] ..\obj\sys.o: In function `__cxa_pure_virtual':
[cc] C:\CooCox\CoIDE\workspace\start_this/sys.c:15: multiple definition of `__dso_handle'
[cc] c:/program files (x86)/gnu tools arm embedded/4.8 2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/armv7e-m/crtbegin.o:(.data+0x0): first defined here
[cc] ..\obj\startup-stm32f4xx.o:(.isr_vector+0x0): undefined reference to `_estack'
[cc] ..\obj\startup-stm32f4xx.o: In function `__Init_Data':
[cc] C:\CooCox\CoIDE\workspace\start_this/startup-stm32f4xx.c:257: undefined reference to `__ctors_start__'
[cc] C:\CooCox\CoIDE\workspace\start_this/startup-stm32f4xx.c:257: undefined reference to `__ctors_end__'
[cc] ..\obj\main.o: In function `Pin<(char)68, 12, (char)72, (PinSpeed)3>::SetPullUp(PullUpMode)':
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `Pin<(char)68, 13, (char)72, (PinSpeed)3>::SetPullUp(PullUpMode)':
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `Pin<(char)68, 14, (char)72, (PinSpeed)3>::SetPullUp(PullUpMode)':
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `Pin<(char)68, 15, (char)72, (PinSpeed)3>::SetPullUp(PullUpMode)':
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `run':
[cc] C:\CooCox\CoIDE\workspace\start_this/OS_Kernel.h:646: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `OS::process<(OS::TPriority)2, 600u>::exec()':
[cc] C:\CooCox\CoIDE\workspace\start_this/main.cpp:67: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::GPIOx'
[cc] C:\CooCox\CoIDE\workspace\start_this/main.cpp:67: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::GPIOx'
[cc] C:\CooCox\CoIDE\workspace\start_this/main.cpp:67: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::GPIOx'
[cc] C:\CooCox\CoIDE\workspace\start_this/main.cpp:67: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::GPIOx
[cc] collect2.exe: error: ld returned 1 exit status
[cc] '

BUILD FAILED
Total time: 2 seconds
помогите исправить, пожалуйста

Сообщение отредактировал viktory_93 - Jun 19 2014, 14:49

Я не знаком с CoIDE. Судя по всему, в проект кроме стартапа от примера включен стартап от CooCox. Вот они и дерутся.
Нужно настроить проект на линковку без использования какого-либо стартапа.
И скрипт линкера не тот.

Ну а вообще, чтобы минимально зависеть от используемой IDE, надо делать так (только что проделал это на голой Win XP в виртуалке):

1. Качаем и ставим свежий gcc-arm-embedded.
   (не забываем поставить птичку "добавить путь в PATH" или что-то типа того)
   
2. Качаем нужные части из msys (не знаю, зачем они нашинковали их на столько кусочков, но уж как есть.):
   
   • core;
   • iconv;
   • libintl;
   • libregex;
   • libtermcap;
   • make;
   • coreutils;
   • bash;
   Распаковываем их все в папку "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q2\"
   То есть, make.exe, sh.exe и прочие утилиты должны попасть в папку "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q2\bin"
   
3. Качаем и ставим svn.
   
4. Пуск - выполнить - cmd.
   Там пишем:
   
   Код
   C:
   cd C:\
   mkdir test
   cd test
   svn checkout http://svn.code.sf.net/p/scmrtos/code/trunk/Samples/CortexM4F/GCC/STM32F4XX STM32F4XX
   cd STM32F4XX
   switch.bat
   cd 1-EventFlag
   make
   
   (Я всё это делаю в файловом менеджере Far, там работать с командной строкой значительно удобнее)
   
5. Убеждаемся в том, что компиляция проходит без ошибок.
   
6. Теперь настраиваем любую интегрированную среду разработки на использование makefile. Всё.

Ура! Билдится! Спасибо
Знать бы теперь как отладку запустить(

Я бы не стал ставить утилиты пакета MSYS в несвойственное им место. Тулчейн может обновиться. Другие среды и тулчейны могут использовать эти утилиты в своих целях. Мало ли ещё какие причины могут быть?
Лучше проинсталлировать MSYS стандартным способом с сохранением пути к нему в переменной PATH. А вот путь к тулчейну я в переменной PATH не сохраняю, а указываю в Project->Properties->C/C++ Build->Environment в переменной PATH (у меня Eclipse Luna, но и в других аналогичных IDE есть похожее). Так удобнее и при экспериментах с разными тулчейнами и с переносимостью проекта лучше.

А у меня путь к самому свежему компилятору прописан в PATH (что позволяет его вызывать из командной строки без полного указания пути), но при необходимости можно в makefile добавить в начало PATH путь к любому другому (подсмотрел у ReAl):

Да, конечно лучше в отдельную папку. Просто я описывал как покороче.

Дело в том, что я не нашёл на сайте mingw нормального инсталлятора MSYS. Самый последний инсталлятор - msys-1.0.11, от 2008 года. Дальше просто куча частей, разложенная в кучу архивов. Я решил, что лучше взять компоненты поновее.

Считаю, что makefile должен работать самостоятельно, на завися от эклипсы. Поэтому все параметры сборки проекта - в нём. Это и для переносимости в том числе.
При экспериментах ничто не мешает мне задать в makefile путь к любому тулчейну, если занадобится. А дефолтные тулчейны - в PATH.



А чем это лучше, вот такого варианта:

(при необходимости заменяем на:

)?

Тем, что не надо перечислять все используемые программы тулчейна, вероятно.

Так их в любом случае придётся перечислять, из-за префикса arm-none-eabi-

mingw-get-setup.exe Можно выбрать то, что нужно.

Это безусловно, если собирать из командной строки. Но если в проект входят ещё и настройки среды (файлы .project, .cproject, что в последнее время сполошь и рядом делается), что удобно для индексатора и discovering, то на мой взгляд лучше по-моему.
Кроме того, "дефолтные тулчейны - в PATH" могут подложить свинью, поскольку оттуда трудно отследить какие именно инструменты вызываются. Например, у меня установлены две версии тулчейна от GCC ARM Embedded и один от CodeSourcery. Чтобы переключиться с одного на другой в Вашем варианте надо поменять переменную PATH и перелогиниться в системе (у меня по крайней мере так). В то время как используя мой вариант, не нужно даже среду перезапускать, а достаточно подправить переменную PATH в среде, при этом автоматически осуществляется редискаверинг и реиндексация.
Мне так показалось удобнее, но я не настаиваю.

О, спасибо, я как-то проглядел. Хотя не люблю я эти веб-инсталляторы

В этом случае сложнее перетащить проект в другую IDE. В моём же варианте - настройки сборки проекта - в makefile, настройки среды - в .project, .cproject.

Нет, я говорил немного о другом. Я говорил о вызове с полным указанием пути к тулчейну.
То есть, дефолтный компилятор вызывается как arm-none-eabi-gcc, а компилятор из другого тулчейна - как C:/tools/cs/2011.09-69/arm-none-eabi-gcc.
При этом никаких изменений в PATH вносить не надо.
Впрочем, я тоже не настаиваю на этом варианте

О! Почти пришли к общему знаменателю. За исключением лишь того, что я не пользуюсь понятием "дефолтного" тулчейна, ибо не понимаю этой сущности. У меня тулчейн всегда конкретный, записанный с полным путём (в переменной PATH среды разработки, в системной же PATH - никаких путей к тулчейнам). Что же касается makefile, то указывать там полный путь, на мой взгляд - моветон, ибо совершенно не переносимо.

Да, мы близки к этому
Дефолтный тулчейн - это, скажем, текущий стабильный. Вышел новый gcc-arm-embedded - я его протестировал, убедился в его работоспособности, и прописал в PATH. И с этого момента все проекты компилируются им.
Вам же, чтобы откомпилировать старые проекты новым тулчейном -- придётся менять настройки для каждого проекта.
(Хотя может быть вы как раз наоборот, не станете менять, ибо раз проект разработан с конкретной версией компилятора, то пусть с ней и сопровождается. В этом случае всё нормально.)
Что касаемо указания полного пути в makefile, то это делается только на время эксперимента, потом убирается. Так что на переносимость не влияет.

Можно вызывать сборку и так:


У меня в Makefile есть такой кусок:

Под Eclipse лень править вызовы для проекта с внешним makefile в Builder Settings, поэтому явно указан CROSS_COMPILE.
Можно убрать (закомментировать) путь к кросс-компилятору и использовать тот, который указан в путях (у меня нет такого).
По поводу переносимости - невелика правка, хуже когда весь проект даже в другую директорию переносится с усилием (по опыту работы с средствами разработки от TI).

P.S. А не следует ли кусок обсуждения про настройку makefile перенести в раздел GNU/OpenSource средства разработки для avr/arm/mips, где это собственно уже и имеется. Для полноты картины?

Хорошо бы, но это может сделать модератор именно этого раздела.