добрый день

в системе установлен стандартный пакет avr-xxx : avr-binutils, avr-gcc, avr-gdb, avr-libc
тестовый проект с makefile - собирается (используется стандартное develop-окружение, без настроек)

добавил в систему avr-Toolchains, распаковал в свои каталоги (использовались готовые/собранные bin-архивы, с уже собранными тулзами)
~/dev/bin/avr/3.4.2/*
~/dev/bin/avr/3.4.3/*
~/dev/bin/avr/3.5.4/*

ВОПРОС 1:
- возможно ли использовать бинарные/готовые сборки avr-Toolchains в нестандартных PREFIX-каталогах (как у меня)?
- что-бы не было коллизий/пересечений со стандартным набором avr-xxx пакетов (стандартные каталоги)
- если "готовые сборки" - нельзя использовать в нестандартных путях, без особых извращений, то можно не объяснять "почему" :о)

ВОПРОС 2:
- если можно (вопрос 1), то какие переменные окружения надо настраивать? (CXX LD ... etc)
- кроме окружения, что ни-будь еще надо настраивать?

ВОПРОС 3:
- тоже самое, применительно к рабочему makefile?
- мейкфайл в данном случае "псевдо-стандартый", можно найте в инете, переменные develop-окружения не менялись, все по умолчанию, т.е. ни какие каталоги/инклуды не прописывались, поэтому - рассматривать будем "сферический makefile в вакууме"

НЕ ВОПРОС:
- можно просто "пофилософствовать по теме", возможно ваши мысли пригодятся :о)

спасибо
...

slackware-xx.x (avr-xxx: стандартный набор slackBuild от sl14.2)
https://slackbuilds.org/

avr-toolchains
http://www.microchip.com/avr-support/av ... mpilers%29

проверьте все бинарники и библиотеки вашего тулчейна утилитой ldd на предмет отсутствующих зависимостей.


лучше не надо.


в makefile конечно придется прописывать пути к тем версиям компиляторов, которые вы планируете использовать



стандартного тулчейнеа с SBo вполне было бы достаточно.

ну ... :о) это совсем лишнее... если бы были поломаны зависимости, то уж точно на профилирующих форумах были-бы упоминания... :о)
как совет, да, если что-то пойдет не так, то, возможно, будет не лишним пробежаться по зависимостям


почему? какие аргументы?
дерево будет лежать в нестандартных путях, а atmel-avr-тулзы изначально собирались на стандарнтые пути (и я даже, сомнемавюсь что на относительные, ск. всего сборка расчитатна на полные пути, от корня, но это мое мнение, могу ошибаться)

немного уточню, возможно, не совсем понятно обьяснил в топике

- в системе установлены стандартные пакеты (по умолчанию) - avr-xxx
- добавляю в кастомные каталоги с бинарными сборками atmel-avr-toolchain-s
- нужно заставить "прозрачно" работать с любой нужной версией и со стандартной и с любой из atmel
- makefile (особенности настройки)

sunjob, у меня "зоопарк" tools-ов. Каждый раз при переходе на нувую версию собираю из исходников со своим prefix-ом, а старые tools-ы не удаляю (на всякий случай оставляю для старых проектов, если требуется исправить ошибку или что-то доработать). Никаких проблем.

Что мешает Вам собрать необходимые tools-ы с нужным префиксом и гарантированно не иметь проблем?

to viiv

немного не по теме... давайте разбираться

надо
1. родная бинарная сборка avr-toolcahin

2. совместное использование ... и установка в нестандартный PREFIX


эта схема, надеюсь, понятна?! вот в этом ключе и будем дальше продолжать царапаться
плюс к этому - makefile

... по поводу "ваших сборок" -


у меня в 10 раз больше давай мериться ...?


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

спасибо

зы



UPDATE

рихтанул makefile



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