Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Проблема с GCC
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
MrYuran
Цитата
Start linking file: Obj/902_430_135.o.
C:\mspgcc\bin\msp430-gcc ./Obj/902_430_135.o ./Obj/ads1241_902.o ./Obj/temperatu
re.o -mmcu=msp430x149 -Wl,--section-start -Wl,.seg_a=0x1080 -Wl,--gc-sections -W
l,-Map=902U.map,--cref -LC:\mspgcc"\bin\lib" -LC:\mspgcc"\msp430\lib" -LC:\mspgc
c"\msp430\include" -LC:\mspgcc"\msp430\include\msp430" -lc -lm -o 902U.elf
/usr/bin/sh: C:mspgccbinmsp430-gcc: command not found
make: *** [902U.elf] Error 127


???
Жирным выделил особо непонятный момент.
Навскидку никто тип грабель не подскажет?

Вот сборочный участок makefile:
Код
# Компиляция: создать объектные файлы из исходников Си.
$(OBJDIR)/%.o: %.c
    @echo Start compile file: $<
    @$(CC) -c $(CFLAGS) $< -o $@
    @echo Compile file: $< - OK.

# Linking.
$(NAME).elf : $(OBJ) makefile
    @echo Start linking file: $<.
    $(CC) $(OBJ) $(LDFLAGS) -o $@
    @echo Linking file: $< - OK.
#
#$(NAME).elf : $(CSRC)
#    @echo $^
#    @$(CC) -c $(CFLAGS) -combine -fwhole-program $^ $(LDFLAGS) -o $(NAME).o
#    $(CC) $(NAME).o $(LDFLAGS) -o $@

$(NAME).a43 : $(NAME).elf
    @$(OBJCOPY) -O ihex $< $@

# Main listing.
$(NAME).lst : $(NAME).elf
    @echo Start create listing file from: $<.
    $(OBJDUMP) -dStl $< > $@
    @echo Create listing file from: $< - OK.


Хотя сомневаюсь, что в нем дело. Точнее, уверен, что не в нем.

Есть предположение, что свежеустановленный цыгвин запускает свой make.exe вместо нужного. Только вот почему ж он такой кривой...
##
Не подтвердилось, с другим то же самое.
Цитата
>mingw32-make all
Start linking file: Obj/902_430_135.o.
C:\mspgcc3\bin\msp430-gcc ./Obj/902_430_135.o ./Obj/ads1241_902.o ./Obj/temperat
ure.o -mmcu=msp430x149 -Wl,--section-start -Wl,.seg_a=0x1080 -Wl,--gc-sections -
Wl,-Map=902U.map,--cref -LC:\mspgcc3"\bin\lib" -LC:\mspgcc3"\msp430\lib" -LC:\ms
pgcc3"\msp430\include" -LC:\mspgcc3"\msp430\include\msp430" -lc -lm -o 902U.elf
/usr/bin/sh: C:mspgcc3binmsp430-gcc: command not found
mingw32-make: *** [902U.elf] Error 127


##
Внезапное развитие событий.
Залочил цыгвин (переобозвал папку на cygwin_) - всё заработало.
Ну и каким образом он мешается?
И почему вчера (до перезагрузки) всё работало?

Насколько понимаю, он свой sh подставляет вместо системного шелла. Как - в упор не понимаю.

Да, так и есть.
Переобозвал sh.exe в sh_ - всё по-старому, нормально работает.

Каким образом sh включается вместо обычного shell - без понятия.
AHTOXA
Всё дело в обратных слешах:
Цитата
C:\mspgcc\bin\msp430-gcc

sh их не любит. Причём разные sh не любят в большей либо меньшей степени, но не любят все до единого.
make, если находит sh в пути, то вызывает его для выполнения команд. Вернее - может вызывать. А если не находит, то запускает команду сам.
Я раньше из-за этого всегда удалял sh из пути. А теперь проникся его (sh) вкусностями, и переделал все makefile под него. В частности, полностью исключил использование обратных слешей.
Было ещё несколько тонких моментов, но в конце-концов всё устаканилосьsm.gif
MrYuran
Цитата(AHTOXA @ May 27 2011, 12:26) *
Всё дело в обратных слешах:

sh их не любит. Разные sh в большей либо меньшей степени, но все.

Это я все понимаю. Не понимаю другого: как sh перехватывает обработку команды из досовского шелла?
AHTOXA
Его make вызывает, при чём тут досовский шелл?
MrYuran
Цитата(AHTOXA @ May 27 2011, 12:30) *
Его make вызывает, при чём тут досовский шелл?

Так, секундочку... С чего бы вдруг?
Да и раньше, без цыгвина, sh нигде не было, а всё работало.
Что-то не то...
AHTOXA
Цитата(MrYuran @ May 27 2011, 14:33) *
Так, секундочку... С чего бы вдруг?

Так он устроенsm.gif

Цитата(MrYuran @ May 27 2011, 14:33) *
Да и раньше, без цыгвина, sh нигде не было, а всё работало.


Ещё раз:
Если make находит sh, то может использовать его. Если не находит - обходится без.
MrYuran
Интересная штука GCC!
Неисчерпаемая, как атом sm.gif

Перевести всё на sh наверно мысль дельная, будет универсальность и кроссплатформенность.
Надо подумать.

Ну а навскидку, какие там ещё подводные грабли, чтобы три раза не спрашивать?
AHTOXA
Это не GCC, это make, он как бы сбокуsm.gif

Грабли - сейчас уже и не вспомню. Помню, что на
Код
echo *** compiling...

sh реагировал весьма своеобразно (раскрывал "shell patterns"). Заменил "***" на "---".
И что-то с rar-ом никак не уживался, этот sh. Сначала я вышел из положения монструозной конструкцией
Код
@cmd /WAIT /C 'start $(RAR) a -r -agyy-mm-dd,hh-nn-ss $(BAKDIR)/$(TARGET)_.rar $(RARS)'

, а потом и вовсе перешёл на 7z.
dxp
Цитата(AHTOXA @ May 27 2011, 15:36) *
Ещё раз:
Если make находит sh, то может использовать его. Если не находит - обходится без.

Именно поэтому - непредсказуемости поведения - всегда исключал это звено из сборки. Только make и штатное окружение консоли венды. Возможно, под линухом с ним всё шоколадно, но в венде смысла в этих сторонних шеллах мало.

Цитата(MrYuran @ May 27 2011, 15:40) *
Перевести всё на sh наверно мысль дельная, будет универсальность и кроссплатформенность.
Надо подумать.

Надо вообще этот make фтопку. Есть более приятные инструменты для этих целей. Я использую уже года 4 или 5 SCons. Питоновый скрипт, по сути. Там можно делать всё - от написания билдеров (функций сборки) до всяких вспомогательных действий типа обработки строк, работы с файлами - словом всё, что доступно полноценному языку программирования. И особенно приятно, что открыв скрипт сборки через полгода без всяких проблем читаешь и правишь код. На make же постоянно приходилось лезть в доку, чтобы вспомнить, что обозначают закорючки типа $< или $@. Да остальной синтаксис через подстановки $(...) не добавляет радости. Птичий язык. Привычка, конечно, многое решает, но за достаточно много лет использования make никогда не испытывал удовольствия от работы с ним. Приобретённый опыт, конечно, помогает по жизни (вот щас c Qt ковыряюсь, пока в рамках его оболочки и организации проектов, там на make основано), но очень рад, что в основном этот этап уже позади. sm.gif
AHTOXA
Цитата(dxp @ May 28 2011, 11:31) *
Именно поэтому - непредсказуемости поведения - всегда исключал это звено из сборки.

Я тоже исключал. А теперь вроде как изучил особенности, и стало всё предсказуемымsm.gif Всё-таки sh изрядно расширяет функциональность make.
Цитата
Надо вообще этот make фтопку. Есть более приятные инструменты для этих целей. Я использую уже года 4 или 5 SCons.

Смотрел немного на него. Вроде заманчиво... Но это, по сути, учить ещё один язык, нужно тратить время и усилия. Пока не складывается.
Есть какая-нибудь ссылка на "быстрый старт"?
dxp
Цитата(AHTOXA @ May 30 2011, 10:57) *
Я тоже исключал. А теперь вроде как изучил особенности, и стало всё предсказуемымsm.gif Всё-таки sh изрядно расширяет функциональность make.

При наличии сконса эта функциональность присутствует нативно и на гораздо более высоком уровне. sm.gif

Цитата(AHTOXA @ May 30 2011, 10:57) *
Смотрел немного на него. Вроде заманчиво... Но это, по сути, учить ещё один язык, нужно тратить время и усилия.
Язык там один надо учить - питон. А это по-любому надо, т.к. оченно могучее средство на всякие случаи. Не настаиваю именно на питоне, есть и другие аналогичные типа Ruby. Тут уж кому что нравится. И большой фактор - окружение, т.е. чтобы было кому вопросы задавать, которые всегда появляются в процессе освоения.

Цитата(AHTOXA @ May 30 2011, 10:57) *
Пока не складывается.
Есть какая-нибудь ссылка на "быстрый старт"?

Хм, специальной ссылки не знаю. Я по документации шёл. Она вполне понятна. Главное - ухватить основную идею. Главное отличие от make там в том, что make основан на правилах: пользователь задаёт правила (явные и неявные), и утилита на основе этих правил строит зависимости. В этом есть определённая гибкость и мощь, но и система эта сложнее для понимания и прогнозирования действий.

В SCons идеология иная: там на уровне скрипта (языка Python) как бы задаётся план действий. Т.е. прямо (путём назначения целей и вызова функций в процессе выполнения скрипта SConstruct - аналог makefile) строится типа списка запланированных действий, которые по окончании прогона SConstruct запускаются на выполнение. Соответственно, весь маршрут линеен и на виду, на любом этапе (которые явные) можно что-то добавить, убрать, откорректировать.

Надо отметить, что в целом SCons - это не аналог make, а скорее аналог связки automake+make, т.е. он автоматом "знает" что запускать по какой платформой и т.п. Но мне такой функционал не был нужен, мне надо было средство - аналог make + удобный набор возможностей по обработке текстовых строк, сопутствующей арифметике, работе с файлами и директориями и т.д. И чтобы всё это было гуманно по отношению к пользователю, т.ч. чтобы после энмесячного перерыва можно было открыть исходник скрипта и спокойно чего читать/редактировать, не обращаясь к документации в качестве справочника. Поэтому я там первым делом удалил весь набор встроенных билдеров (функций сборки) и добавил свои.

Если интересуешься, то возьми для начала какой-нибудь мой вариант из примеров для MSP430. Если как-то знаком с питоном, что порог вхождения там намного ниже, чем с тем же make. Все вопросы кидай в асю, с удовольствием отвечу. sm.gif Ну, а для начала просто доку на один раз пробежать на досуге.
MrYuran
Цитата(dxp @ May 30 2011, 11:20) *
Если интересуешься, то возьми для начала какой-нибудь мой вариант из примеров для MSP430.

А где взять? Я бы тоже попробовал.
Тем более что пришлось записаться в ряды извращенцев и запускать MSPGCC из-под VS, со всеми сопутствующими издержками типа перекодировки потока вывода ошибок через sed
_Pasha
dxp, спасибо за сконс! Я как-то интересовался им ранее, но, видимо, тогда еще не дорос.
AHTOXA
Цитата(dxp @ May 30 2011, 13:20) *
Если как-то знаком с питоном, что порог вхождения там намного ниже, чем с тем же make.

В том-то и дело, что совсем не знакомsm.gif Да и все мои задачи на данный момент я вроде бы худо-бедно решаю при помощи make... Но всё же почитаю доку на SCons на досугеsm.gif

Цитата(MrYuran @ May 30 2011, 13:39) *
А где взять? Я бы тоже попробовал.

тут sm.gif
MrYuran
Вот кое-что с хабра...
demiurg_spb
Цитата(AHTOXA @ May 30 2011, 12:33) *
Да и все мои задачи на данный момент я вроде бы худо-бедно решаю при помощи make...
Аналогичная картина. Нет стимула что-либо менять. Человек - ленив по природе.
Непомнящий Евгений
Использую сконс. Доволен! sm.gif

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

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

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

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

По сравнению с мейком билд скрипт обычно короче (и понятнее).

Очень просто организовать компиляцию одной и той же программы под несколько целевых архитектур разными компиляторами.

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

Минусы сконса проистекают из его плюса - использования полноценного языка программирования:
- ИДЕ не умеют подхватывать билд файлы сконса или автоматически их редактировать
- можно навернуть такого, что посторонний человек (или сам через пару лет) не разберется sm.gif
- Он сравнительно медленный. Питон - интерпретируемый язык. Кроме того, сконс в отличие от waf многое делает при каждом билде - нет отдельного шага конфигурации.

По довольно большому моему десктопному проекту ребилд выглядит так:
Total build time: 223.119000 seconds
Total SConscript file execution time: 1.909000 seconds
Total SCons execution time: 4.593001 seconds
Total command execution time: 216.616999 seconds

Повторная попытка сбилдить проект (по факту ничего не делается, сконс определяет что нет изменений и завершается):
Total build time: 6.139000 seconds
Total SConscript file execution time: 1.917000 seconds
Total SCons execution time: 4.076000 seconds
Total command execution time: 0.146000 seconds

Однако сконс умеет распараллеливать билд на несколько потоков, а также использовать общий кэш - если у вас несколько (несильно) разных версий проекта используют общий кэш, скорость компиляции сильно вырастет.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.