При линковке возникла следующая ошибка (причём и раньше сатлкивалась с ней ,но так и не выяснила ,что она значит):
Linking: main.elf
arm-elf-gcc -mcpu=arm7tdmi -I. -g -DROM_RUN -DVECTORS_IN_ROM -D__WinARM__ -D__WINARMSUBMDL_AT91SAM7S256__ -O0 -ffunction-sections -fdata-sections -Wall -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wunused -Wa,-adhlns=common/Cstartup.lst -I./common -I../../inc -I../../conf -MD -MP -MF .dep/main.elf.d common/Cstartup.o common/swi_handler.o common/Cstartup_SAM7.o main.o dbgu.o syscalls.o swi_handler_user.o systime.o --output main.elf -nostartfiles -Wl,-Map=main.map,--cref,--gc-sections -L./common -L../../ -lefsl -T./common/AT91SAM7S256-ROM.ld
/src/gnutools/arm-elf/bin/../lib/gcc-lib/arm-elf/3.2.1/../../../../arm-elf/bin/ld: cannot find -lg
collect2: ld returned 1 exit status
make: *** [main.elf] Ошибка 1

Может ,линкер не находит какую-то опцию??? ПОдскажите ,плз!!! Очень надо!

Линкер не может найти библиотечку c именем g Что-то типа g.a

а может libg.a

А мне кажется, что автор хочет подключить библиотеку libg.a, но ключ -l указывает не линкеру (ld), а gcc. Соответственно, когда команда доходит до линкера, линкер воспринимает -lg не как команду -l с параметром g, а как имя объектного файла, который и не может найти. Но я не вижу в командной строке -lg, вижу только -g. Вообще, эта командная строка являет собой какую-то дикую смесь из опций компилятора (-ffunction-sections -fdata-sections -Wall -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -MD -MP -MF .dep/main.elf.d), ассемблера (-Wa,-adhlns=common/Cstartup.lst) и линкера (--output main.elf -nostartfiles -Wl,-Map=main.map,--cref,--gc-sections -L./common -L../../ -lefsl -T./common/AT91SAM7S256-ROM.ld). Подозреваю, что причина в этом.

ZAA: прикрепите к сообщению архив с вашим makefile, похоже ошибка где-то в нем.

Линкер не находит библиотеку libg.a
Эта библиотека то же самое что и libc.a но с отладочной информацией.


gcc без ключа -c выполняет линковку путем запуска ld.
Но для встраиваемых приложений (типа arm-elf-gcc) лучше использовать arm-elf-ld явно.
То есть разделить компиляцию и линковку, и выполнять компиляцию с ключем -c а потом уже линковать все полученные *.o файлы путем вызова arm-elf-ld

Прикрепляю архив проекта. Этот самы злополучный Makefile находится в папке examples->arm_at91sam7. Кстати, это я пытаюсь пример для At91 с файловой системой efsl скомпилировать. причём библиотека libefsl.a нормально собралась.
P.S. Спасибо за ответы!



А где вообще взять эту библиотеку и откуда собственно она берется? Просто я не сильно разбираюсь в тонкостях компиляции и линковки

Это часть libc. У вас видимо newlib? Вот там она и есть.

Посмотрел проект.
Ошибка видимо отсюда (Makefile строка 128)

Замените на



Если соберется без ошибок, то для включения отладочной информации попробуйте опции

или варианты
DEBUG = 1 или DEBUG = 2 или DEBUG = 3

Спасибо - попробую

А чем это лучше? Чем не устраивает использование gcc для линковки? Может я чего-то не знаю?

А будет ли ld автоматически работать с multilib? Ведь когда используешь gcc нужная библиотека выбирается автоматически в зависимости от параметров (например -mthumb).

Еще я когда-то давно натыкался в инете на обсуждение какой-то проблемы линковки и рекомендация была использовать для линковки gcc. Мол в ld баг и gcc об этом знает и обходит его. Вообще похоже на бред, но почему бы так не делать? Чем ld лучше?

Ни то ни другое не обязательно. Используйте то, что Вам больше нравиться (ну или то, что болле поддается Вашему контролю).
Использовать gcc для линковки никто не запрещает, а в слуае g++ так и вообще лучше не думать о том какие файлы передать ld для линковки вручную.
На мой взгляд при arm-elf ликовка явным вызовом ld более подконтрольна чем gcc.
Если Вам нравиться линковать вызовом gcc и Вы хорошо себе представляете, что он за собой тащит - пожалуйста.
Одна из проблем с gcc - это libg.a. Часто ее нет, а gcc ее хочет. Часто замена вызова gcc на ld и явное указание -lc вместо -lg (как и явное перечисление действительно нужных стартфайлов в правильном прядке) решает все проблемы такого рода, как в начальном посте.
В большинстве случаев вообще можно обойтись одним crt0.o, а gcc часто тащит crti.o, crtn.o, Mcrt0.o и еще много чего интересного но не нужного в конкретной программе.

С мультилиб, по крайней мере -mthumb у меня работает (правда не знаю зачем - ни разу thumb не использовал в реальных проектах). Для других случаев (типа -mbig-endian) у меня отдельный тулчейн.

У меня в NEWLIB, оказывается, есть эти библиотеки - libg.a, libc.a, libm.a. Вот. Поместила в свой проект - и проблема исчезла!!! Спасибо большое всем за ценные советы!!! Очень помогло