-
Постов
340 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о alx2
-
Звание
Местный
- День рождения 02.06.1972
Контакты
-
Сайт
Array
Информация
-
Город
Array
Посетители профиля
2 771 просмотр профиля
-
И правильно делает, что выдает. Смотрите в руководстве, как надо указывать ссылки на файлы в архивах: You can also specify files within archives by writing a pattern matching the archive, a colon, then the pattern matching the file, with no whitespace around the colon. `archive:file' matches file within archive `archive:' matches the whole archive `:file' matches file but not one in an archive
-
Ну вот. Оказывается, файл-то не heap_1.o, а ..\obj\heap_1.o! То есть он не в текущем каталоге, а в ../obj. А в скрипте линкера Вы как этот файл указали?
-
Можете показать фрагмент map-файла, где говорится о загрузке этого файла (когда Вы собираете проект без вынесения его .bss в SDRAM)? В зависимости от того, отдельный ли это файл, или часть библиотели, либо указанием этого файла в командной строке линкера, либо указанием библиотеки через -l... Можете показать команду, которой линкуете проект?
-
Не понял, зачем Вы это здесь написали... Вам непонятна суть ошибки? Линкер не нашел указанный в скрипте объектный файл. Такой файл вообще в вашем проекте есть?
-
Наверное что-то типа .bss.sdram : { heap_1.o(.bss) } >SDRAM
-
Ну тогда либо у Вас в libm нет sinf/cosf (что вряд ли), либо баг линкера.
-
Кроме libm надо еще libc - там находятся memcpy/memset. Но Вы, похоже, и libm не указали, судя по тому, что линкер не находит powf, sinf и т.п., которые должны там быть... Если я правильно понял, memset требуется, например, функции wave_startrecording(). Смотрите map-файл - там должно быть написано, кто какой символ потребовал.
-
WinAVR + float == просто беда
alx2 ответил ARV тема в GNU/OpenSource средства разработки
Видимо, те же символы линкер находил в какой-то еще из используемых Вами библиотек, и код там не очень адекватный... Смотрите map-файл, там много полезной информации о том, откуда что взяли... -
GCC for ARM 64-bit
alx2 ответил Tarbal тема в GNU/OpenSource средства разработки
Что плохого в самостоятельном строительстве? -
Проверьте, какие часовые пояса установлены на ваших двух компьютерах. Неоднократно обнаруживал на компьютерах коллег по работе, что в системе был установлен неверный часовой пояс. Причем пользователь компьютера этого не замечал, так как системное время также было установлено со сдвигом, компенсировавшим разницу часовых поясов.
-
Покажите полностью команду, которая завершается приведенными Вами выше ошибками. Покажите также (для полноты понимания ситуации) вывод команд: objdump -a <ваша библиотека> | grep syscalls nm <ваша библиотека> | grep _exit Ничего странного в этом нет. Если Вы при линковке, к примеру, сначала укажете библиотеку с файлом syscalls.o, на символы которого ссылок нет, то линкер, естественно, syscalls.o из библиотеки не загрузит. А потом Вы, допустим, укажете фйл, ссылающийся на что-то из syscalls.o - и, естественно, получите ошибку "символ не определен". Точно так же очевидно, что если Вы поменяете местами этот файл с библиотекой, ошибки не будет, так как на момент чтения библиотеки у линкера уже будет неопределенная ссылка, скажем, на тот же _exit, и линкер разрешит ее загрузкой syscalls.o из библиотеки.
-
Извините, но по-моему у Вас в голове каша. Линковка производится программой ld, так как именно это и есть линкер. Программа ar - это архиватор, который объединяет объектные файлы в архив (библиотеку). Программа же gcc - это просто враппер, который сам по себе никакой обработки компонентов программы не выполняет, а вызывает для этого другое программы - препроцессор, компилятор, ассемблер, линкер. Каким именно операции будут выполнены, зависит от параметров командной строки. Думаю, Вам стоит разобраться, из каких этапов (операций) состоит процесс сборки программы, что для каждого этапа является входными данными, а что - результатом. И сам вопрос ваш, действительно, непонятен. Если Вы знаете и как получить библиотеку, и как получить hex-файл, какая проблема выполнить и то, и другое? Указать кому/чему? make'у? Написать в Makefile что-то типа: liba.a: file1.o file2.o file3.o arm-none-eabi-gcc-ar cq $@ $^ arm-none-eabi-gcc-ranlib $@
-
Это не о том: NAME ldd - print shared library dependencies OPTIONS --version Print the version number of ldd.
-
Sysupgrade / switch root to ram
alx2 ответил vgovseychuk тема в Linux
Да, верно. В 2014.10 просто read бэдблоки пропускает. Я использую другую версию, там просто read не пропускает... -
Sysupgrade / switch root to ram
alx2 ответил vgovseychuk тема в Linux
Не понял, о каком скрипте Вы говорите. Возможно, Вы не совсем понимаете, как работают менеджеры пакетов. В системе имеется список пакетов, установленных в текущий момент. При необходимости обновиться менеджер пакетов скачивает из репозитория свежий список пакетов и сравнивает с установленными. Если он видит в списке пакет более поздней версии, чем установленный, то новый пакет скачивается и устанавливается. Все это (и многое другое, я тут сильно упростил процесс) выполняет готовый менеджер пакетов, Вам как разработчику об этом заботиться не надо, разве что не забывать менять версию пакета (да и это можно автоматизировать, у меня версии пакетов формируются автоматически из ревизии SVN)... Хм... Да, mdt read нет. Но чем Вас не устраивает mtd verify? Смотрите документацию/код вашего бутлоадера. Вы, кстати, не сказали, каким бутлоадером пользуетесь. Например u-boot может читать как с учетом, так и без учета бэдблоков. В вашем случае, очевидно, бэдблоки надо учитывать, поэтому вместо nand read следует использовать nand read.jffs2 (если у Вас u-boot). То же самое касается nand write. В общем случае - не нормально. Это может быть нормально, если целевой раздел (куда мы копируем) больше размера копируемых данных, и даже при наличии бэдблоков данные в него заведомо влезут. Иначе, если в процессе записи будет пропуск бэдблока, запись "вылезет" за пределы раздела. У Вас здесь, кстати, вообще какая-то путаница с размерами: в первом сообщении Вы пишете, что размер раздела fdt 128k. А теперь Вы пишете в него данные размером 0x40000, то есть 256k! :) Надеюсь, это не ошибка, а Вы просто поменяли разбивку... Это - на Ваш вкус. Лично я именно nandwrite использую для обновления ядра. И еще вопрос - зачем Вы fdt и ядро переписываете дважды (через промежуточные разделы)? С файловой системой понятно - Вы не можете переписать ее пока она смонтирована. Но с fdt и kernel-то какая проблема? Вы не перемудрили ли здесь?