LINUX.ORG.RU

Избранные сообщения WRG

Ошибка при сборке GCC в crossdev

Форум — Development

Скачал я stage3-amd64-20161013.tar.bz2 и portage-latest.tar.bz2, распаковал, сделал туда chroot (все делал по инструкции из https://wiki.gentoo.org/wiki/Chroot/ru, исходная ОС - Ubuntu 14.04.5 LTS если это имеет какое-то значение), установил crossdev и решил вот это сделать: 

# crossdev -v -t armv7-none-linux-gnueabi --g 4.9.3 --ov-output /usr/local/portage
Оно успешно собрало бинутилсы, но на этапе сборки GCC произошла ошибка 
checking for armv7-none-linux-gnueabi-gcc... /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/./gcc/xgcc -B/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/./gcc/ -B/usr/armv7-none-linux-gnueabi/bin/ -B/usr/armv7-none-linux-gnueabi/lib/ -isystem /usr/armv7-none-linux-gnueabi/include -isystem /usr/armv7-none-linux-gnueabi/sys-include   
checking for suffix of object files... configure: error: in `/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/armv7-none-linux-gnueabi/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Makefile:9790: recipe for target 'configure-target-libgcc' failed
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build'
Makefile:840: recipe for target 'all' failed
make: *** [all] Error 2
 * ERROR: cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev'`,
 * the complete build log and the output of `emerge -pqv '=cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev'`.
 * The complete build log is located at '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build'
 * S: '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/gcc-4.9.3'
 * 
 * Please include /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/gcc-build-logs.tar.bz2 in your bug report.
 * 

>>> Failed to emerge cross-armv7-none-linux-gnueabi/gcc-4.9.3, Log file:

>>>  '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/build.log'
 * Messages for package cross-armv7-none-linux-gnueabi/gcc-4.9.3:
 * ERROR: cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev'`,
 * the complete build log and the output of `emerge -pqv '=cross-armv7-none-linux-gnueabi/gcc-4.9.3::crossdev'`.
 * The complete build log is located at '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build'
 * S: '/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/gcc-4.9.3'
 * 
 * Please include /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/gcc-build-logs.tar.bz2 in your bug report.
 *
вот config.log из /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/armv7-none-linux-gnueabi/libgcc/ https://paste.fedoraproject.org/454717/51559147/

Вот конкретно момент, по которому видно, в чем проблема: 

conftest.c:1:0: error: target CPU does not support ARM mode
 /* confdefs.h */
 ^
configure:3392: $? = 1
configure:3580: checking for suffix of object files
configure:3602: /var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/./gcc/xgcc -B/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/./gcc/ -B/usr/armv7-none-linux-gnueabi/bin/ -B/usr/armv7-none-linux-gnueabi/lib/ -isystem /usr/armv7-none-linux-gnueabi/include -isystem /usr/armv7-none-linux-gnueabi/sys-include    -c -g -O2 -pipe  conftest.c >&5
conftest.c:1:0: error: target CPU does not support ARM mode
 /* confdefs.h */
 ^
configure:3606: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3620: error: in `/var/tmp/portage/cross-armv7-none-linux-gnueabi/gcc-4.9.3/work/build/armv7-none-linux-gnueabi/libgcc':
configure:3623: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Там зачем-то проверяется, умеет ли мой процессор запускать ARM бинарники? Он и не обязан это уметь, я собираю кросскомпилятор. Как сделать чтобы crossdev собрал мне GCC который бы создавал бинари под ARM и запускался на x86-64?

Если нужны какие-то дополнительные логи - могу предоставить.

 , , , ,

SZT
()
5 комментариев

Самодельный электродвигатель

Форум — Science & Engineering

Срочно нужен электродвигатель (для конкурса на робота), поэтому нет возможности ждать заказа (HobbyKing последнюю посылку доставил за 60 дней), а он не настолько нужен (есть резервные варианты с худшими параметрами), чтобы пытаться купить с переплатой в России. К тому же желательны вполне определённые характеристики. Поэтому было принято решение попробовать сделать свой двигатель. Бесколлекторный (если бы покупали - то тоже такой конструкции). Если обычно бесколлекторные двигатели отличаются большой мощностью при малых габаритах (из-за этого их собственно и используют во всех нормальных моделях авто и авиа, кроме китайских детских игрушек и совсем маленьких моделек), то в данном случае к плюсам прибавится очень простая конструкция.

Мотор будет напрямую крутить колёсо, ожидаемая мощность около киловатта. Соответственно, он будет состоять из двух частей. Подвижный барабан, у которого на внутренней стороне приклеены неодимовые магниты, а внутри сердцевина с катушками по кругу. Внешний диаметр барабана 15 сантиметров (он, собственно, будет и колесом одновременно, если его обклеить снаружи резиной или сделать что-то в этом роде).

Имеется доступ к фрезерному станку с ЧПУ, поэтому проблем с точным изготовлением некоторых деталей не будет. Собственно, конструкция барабана уже продумана (как из тех материалов, что есть сделать хороший барабан) и он будет сделан в ближайшем будущее. Конструкция крепления барабана к сердцевине (с использованием подшипника, разумеется) тоже. А вот с катушками есть проблема. В нормальных заводских движках используется электротехническая сталь (как в низкочастотных трансформаторах). У нас в городе её не продают (а то можно было бы на том же ЧПУ выпилить сколько нужно слоёв и сложить). Можно ли мотать катушки на ферритовых стержнях?

Также было бы не плохо узнать методику расчёта обмоток двигателя (люди точно перематывают заводские движки для получения новых параметров, так что алгоритмы должно быть известны, а, возможно, даже есть готовые программы расчёта). И как на неё повлияет использование феррита.

 

KivApple
()
69 комментариев (стр. 2)

Запилите кто-нибудь нормальный обзор Rust

Форум — Development

Коллеги, а не мог бы кто-нибудь из вас запилить нормальное сравнение Rust с плюсами? В последнее время rust то и дело упоминают как будущего убийцу с++, вот мне и стало интересно. Но изучать новый язык у меня сейчас времени нет, а все обзоры и сравнения (вот последнее на хабре: http://habrahabr.ru/post/225507/) сводятся к следующему:

Возьмем пример стандартного кода на с++ 

$ cat test.cpp
int main()
{
    *((int*)nullptr) = 0xdeadbeef;
}
Давайте его запустим, и посмотрим, что получится: 
$ g++ -std=c++0x -o testcpp test.cpp && ./testcpp
Segmentation fault
Как видите, с++ позволяет выстрелить себе в ногу!
А теперь давайте посмотрим, что будет, если этот же код попытаться скомпилировать rust: 
rust -o testrust test.cpp
test.cpp:1:1: 1:4 error: expected item but found `int`
test.cpp:1 int main()
           ^~~
Смотрите, компилятор rust не скомпилировал этот код и сохранил нам ногу! ergo, rust - убийца с++.

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

Если где-то есть уже что-то подобное в сети, киньте ссылку.

UPD: нашел очень качественное сравнение с++ и go (http://kidoman.io/programming/go-getter.html).
tl;dr: товарищ сравнивал производительность, в качестве демонстрационной программы использовал трассировщик лучей. В первой серии go победил после множества оптимизацй, во второй серии с++ после таких же оптимизаций одолел go на одном ядре, в третьей серии в с++ впилили многопоточность, и он разорвал go пополам.
Стоит обратить внимание, что рейтрейсер на c++ в этом примере написан без единого new/delete.
Буду очень признателен, если кто-то напишет подобное сравнение с++ с rust, а еще лучше - если портирует трассировщик из примера выше на rust о объяснит, почему он лучше (там уже на несколько других языков портировали).

 , ,

ddos3
()
148 комментариев (стр. 2 3)