Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, c-smile, Вы писали:
CS>>Да медленно, но тем не менее работает. K>Поздравляю. Пробовал кросс-компилить или так и забил на это дело?
Забил. Поленился переводить существующий проект (Code::Blocks) на make.
Code::Blocks на Raspbian заработал поэтому и не дергался особо.
Здравствуйте, Pzz, Вы писали:
A>>и только в самом конце собираю на Raspberry Pi.
Pzz>А зачем ты это вообще делаешь? Чем плох кросс-скомпилированный исполняемый файл?
Тем, что я не хочу трахаться с кросс-компиляцией.
Объяснить тебе какие проблемы вызывает кросс-компиляция?
Здравствуйте, c-smile, Вы писали:
CS>Насколько я понимаю это надо делать true Linux way — собирать его на target устройстве.
В целом это проще всего.
CS>Альтернативно можно попробовать cross-compiling, но насколько я понимаю это работает только для простых случаев. Или я ошибаюсь?
Нет, это работает для любых случаев и в основном так и работают, особенно когда речь идёт о слабых устройствах. Но в случае с распберри — наверное можно и на целевом устройстве всё делать, если у тебя не гугль хром по времени компиляции и требованиям к железу.
CS>Поэтому вопрос по Raspberry Pi dev device, какой он должен быть, например SSD нужен или нет?
Никаких принципиальных отличий от обычного компьютера нет. Чем лучше "железо", тем удобней работать. Естественно SSD сделает работу комфортней. Возможно грузиться придётся с SD-карты, я точно не знаю, умеет ли он грузиться с USB.
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Если речь именно про Raspberry Pi, то это почти обычный дебиан. Для юзерспейса тебе особо ни о чём думать не надо.
А если речь про embedded устройства, там обычно пользуются кросс-компиляцией. Проекты buildroot, yocto из популярных, многие просто своими скриптами сами линукс собирают.
Здравствуйте, Zhendos, Вы писали:
Z>Сборка на устройстве это может быть стресс-тест для проверки что ты ядро правильно Z>портировал или еще какой надобности
Мне вот интересно, есть ли хоть одна надобность, не говоря уже о "еще какой". Единственное, что приходит на ум — отсутствие нормального кросс-компилятора для целевой платформы. Но такое, насколько я знаю, кончилось еще лет двадцать назад.
Здравствуйте, c-smile, Вы писали:
CS>можно попробовать cross-compiling, но насколько я понимаю это работает только для простых случаев.
Какие-либо проблемы с кросс-компиляцией возможны лишь в том случае, когда целевая платформа — мейнстрим, и большинство занимается разработкой непосредственно на ней, а кросс-компилятор для платформы, которая у Вас, сделан "на отъ.ись" (ограниченный, тормозной, глючный и т.п.). Например, если б Вам потребовалось на RPi собрать бинарники для винды.
Если же основная платформа — винда/линукс/макось, а целевая используется в основном во встроенном виде, то собирать надо как раз на основной, кросс-средствами.
Здравствуйте, alpha21264, Вы писали:
Pzz>>А зачем ты это вообще делаешь? Чем плох кросс-скомпилированный исполняемый файл? A>Тем, что я не хочу трахаться с кросс-компиляцией. A>Объяснить тебе какие проблемы вызывает кросс-компиляция?
А объясни. Очень любопытно, как это объяснить тому, кто сам никогда не трахался с кросс-компиляцией. В теории там всё прозрачно, теоретеги нагадят на доску и улетят всем рассказывать, как они тебя уделали на любой пример из жизни ответят, что у тебя руки кривые, а на самом деле всё работает.
Здравствуйте, /aka/, Вы писали:
A>любопытно, как это объяснить тому, кто сам никогда не трахался с кросс-компиляцией.
Особенно любопытно, как это объяснять тем, кто делает софт для микроконтроллеров Intel/PIC/AVR, для которых "нативных" компиляторов не существует в природе.
A>В теории там всё прозрачно
Если на практике непрозрачно, причина может быть только одна — кривая кросс-система. Других причин не бывает.
Здравствуйте, Marty, Вы писали:
CS>>Поэтому вопрос по Raspberry Pi dev device, какой он должен быть, например SSD нужен или нет? M>Хм, там по моему, интерфейс для накопителей отсутствует вообще. Флешка, и всё. У меня правда RPI2, я и на самом деле не добрался пока с ней поковыряться, один раз запустил и отложил
Так оно, но есть исключение. У проца RPi4 есть PCIе шина, но она используется для контроллера USB3. Есть рецепты, как подпаять PCIe слот к PRi4 А бывает RPi4 в виде IO Board + Compute Module, там один слот x1 из коробки.
Здравствуйте, Lucky Cat, Вы писали:
LC>Что то написанное на C на малинке собирается в сравнимое с интеловским хостом, на котором 12 Гб ОЗУ и несколько гигагерцный проц.
Если убрать с хоста 8 Гб ОЗУ, а процу добавить гигагерц, оно соберется как-то иначе?
Здравствуйте, Kernan, Вы писали:
K>все советы по кросскомпилированию в интернете походят для несложных проектов, что-то комплексное придётся компилировать через боль.
Это может означать только то, что средства кросс-компиляции для линукса по определению кривы, и чрезмерно завязаны на локальную среду, чего в них быть не должно. Виндовые средства в этом смысле правильнее, поскольку винда до самых недавних пор активно использовалась лишь на интеловской архитектуре, отчего шансов обнаружить ее на целевой платформе и завязаться на локальную среду практически не было. А то, что линукс уже давно идет практически везде, создает изрядный соблазн делать вместо правильной кросс-компиляции костыльную, отсюда и вся эта боль.
Здравствуйте, B0FEE664, Вы писали:
BFE>Процессоры ARM различаются по своей архитектуре. Для каждой модели процессора существует своя процедура кросс компиляции
Все настолько ужасно, что при смене модели ARM требуется менять процедуру, а не просто ключи у компилятора/линкера? Или это требуется лишь для самых новых моделей, для которых еще не подтянули универсальных кросс-средств?
BFE>Т.е. если на сайте поставщика системы написано, что они рекомендуют использовать, скажем, Ubuntu такой-то версии, то мы берём эту Ubuntu указанной версии
Вот это меня тоже всегда поражало в линуксах — в системах, созданных и продвигаемых под эгидой взаимной совместимости, шаманства от возможной несовместимости наблюдается подозрительно много.
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Процессоры ARM различаются по своей архитектуре. Для каждой модели процессора существует своя процедура кросс компиляции ЕМ>Все настолько ужасно, что при смене модели ARM требуется менять процедуру, а не просто ключи у компилятора/линкера? Или это требуется лишь для самых новых моделей, для которых еще не подтянули универсальных кросс-средств?
Прошло 5 лет и сейчас стало намного проще: новые версии gcc хорошо понимают ARM архитектуру и проблем с компиляцией стало существенно меньше. Можно даже из-под винды делать кросскомпиляцию и отладку, но есть некоторые проблемы пример
.
Так что сейчас удобнее работать так: устанавливаем WSL с любимой системой (при желании настраиваем XServer, хотя пишут, что для последней версии WSL даже этого на надо) и из под неё кроскомпилируем (и даже удалённо отлаживаем).
BFE>>Т.е. если на сайте поставщика системы написано, что они рекомендуют использовать, скажем, Ubuntu такой-то версии, то мы берём эту Ubuntu указанной версии ЕМ>Вот это меня тоже всегда поражало в линуксах — в системах, созданных и продвигаемых под эгидой взаимной совместимости, шаманства от возможной несовместимости наблюдается подозрительно много.
Разве взаимная совместимость кем-то декларировалась? Вроде бы нет. Разве что на уровне исходников и то: только при одинаковом наборе версий библиотек.
Здравствуйте, B0FEE664, Вы писали:
BFE>Прошло 5 лет и сейчас стало намного проще: новые версии gcc хорошо понимают ARM архитектуру
Что мешало им отлично ее понимать еще 15-20 лет назад, когда она более-менее заметно пошла в работу?
BFE>проблем с компиляцией стало существенно меньше.
Так их не должно быть вообще, если компилятор/линкер явно не кривые.
BFE>Можно даже из-под винды делать кросскомпиляцию и отладку, но есть некоторые проблемы BFE>пример
А менее надуманные проблемы есть?
BFE>сейчас удобнее работать так: устанавливаем WSL с любимой системой (при желании настраиваем XServer, хотя пишут, что для последней версии WSL даже этого на надо) и из под неё кроскомпилируем (и даже удалённо отлаживаем).
Это всегда было удобнее, отчего и возникла идея кросс-компиляции. Под ту же винду так было с незапамятных времен — например, для Windows CE/Mobile под ARM/MIPS отродясь не было средств разработки, все делалось на интеловских десктопах. И линуксовые прошивки для большинства устройств на тех же ARM/MIPS физически невозможно собрать на целевой платформе — только кросс-средствами. Про микроконтроллеры и говорить нечего.
BFE>Разве взаимная совместимость кем-то декларировалась? Вроде бы нет. Разве что на уровне исходников и то: только при одинаковом наборе версий библиотек.
О том и речь, что идея системы, призванной обеспечить совместимость, вылилась в генератор всевозможных несовместимостей.
Здравствуйте, alpha21264, Вы писали:
Pzz>>А зачем ты это вообще делаешь? Чем плох кросс-скомпилированный исполняемый файл?
A>Тем, что я не хочу трахаться с кросс-компиляцией. A>Объяснить тебе какие проблемы вызывает кросс-компиляция?
Мне кажется, больше половины тех программ, которыя я так или иначе в жизни писал, кросс-компилировались. Я привык.
Здравствуйте, Pzz, Вы писали:
A>>Объяснить тебе какие проблемы вызывает кросс-компиляция?
Pzz>Мне кажется, больше половины тех программ, которыя я так или иначе в жизни писал, кросс-компилировались. Я привык.
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Прошло 5 лет и сейчас стало намного проще: новые версии gcc хорошо понимают ARM архитектуру ЕМ>Что мешало им отлично ее понимать еще 15-20 лет назад, когда она более-менее заметно пошла в работу?
Я могу только догадываться.
BFE>>проблем с компиляцией стало существенно меньше. ЕМ>Так их не должно быть вообще, если компилятор/линкер явно не кривые.
Проблема не только в компиляторах/линкерах, но и в библиотеках.
BFE>>Можно даже из-под винды делать кросскомпиляцию и отладку, но есть некоторые проблемы BFE>>пример
. ЕМ>А менее надуманные проблемы есть?
В смысле — надуманные? Это реальная проблема и вряд ли её кто-то будет чинить.
Но есть и другие. Скажем есть библиотека, а она подключает заголовок, которой нет в системе. Значит этот файл надо копировать из системы, а он тянет другой и так все файлы, один за другим переползают в sysroot...
и как только окажется, что sysroot есть линки, то процесс копирования файлов перестаёт быть томным.
И если окажется, что компилятор по какой-то причине не понимает вот этот вот заголовок из недр sysroot'a или понимает его не правильно...
BFE>>сейчас удобнее работать так: устанавливаем WSL с любимой системой (при желании настраиваем XServer, хотя пишут, что для последней версии WSL даже этого на надо) и из под неё кроскомпилируем (и даже удалённо отлаживаем). ЕМ>Это всегда было удобнее, отчего и возникла идея кросс-компиляции.
Это никогда не было удобным, а практика кросс-компиляции возникла из-за нехватки ресурсов для разработки на целевой платформа.
ЕМ>Под ту же винду так было с незапамятных времен — например, для Windows CE/Mobile под ARM/MIPS отродясь не было средств разработки, все делалось на интеловских десктопах. И линуксовые прошивки для большинства устройств на тех же ARM/MIPS физически невозможно собрать на целевой платформе — только кросс-средствами. Про микроконтроллеры и говорить нечего.
И несмотря на многолетние наработки безглючных средств отладки так и не было произведено.
BFE>>Разве взаимная совместимость кем-то декларировалась? Вроде бы нет. Разве что на уровне исходников и то: только при одинаковом наборе версий библиотек. ЕМ>О том и речь, что идея системы, призванной обеспечить совместимость, вылилась в генератор всевозможных несовместимостей.
Так ведь не было такой идеи. Ну или я о ней никогда не слышал.
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>Мне кажется, больше половины тех программ, которыя я так или иначе в жизни писал, кросс-компилировались. Я привык.
ЕМ>И что, много было проблем?
Единственное, что приходит на ум — отсутствие нормального кросс-компилятора для целевой платформы. Но такое, насколько я знаю, кончилось еще лет двадцать назад.
Ну или я о ней никогда не слышал.
