В общем, компилятор выдает ошибки, типа

Что говорит о том что он не видит .h файлы.
Сами .h файлы физически есть, в /usr/avr/include
Когда-то я этот успешно решил, но что я тогда сделал - убей, не помню. где-то в линуксе писал пути к этим бибилиотекам. Пробовал установливать PATH в /usr/avr и /usr/avr/include, но не помогает.

А почему они там, а не в /usr/lib/avr/include/ ?
Ну можно, конечно, в makefile прописать -I/usr но это как-то странно

Нет. Конкретно сообщение выше говорит о том, что DDRB не определено. Что скорее всего означает, что вы забыли сделать #include <avr/io.h>
Если бы этого файла не было бы, компилятор ругался именно на отсутствие вкладываемого .h файла через #include, что если и было, то вы показали не ту ошибку.

Добавлено after 1 minute 21 second:
PS: Но на всякий случай путь для #include прописывается в переменной окружения CPATH, а не PATH.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Не знаю, это не я, это пакетный менеджер. А че он там делает, я не разбираюсь.
В любом случае, скопировать их в /usr/lib/avr/include тоже не помогло.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Shuspano, не с той стороны заходите, не страдайте ерундой. В сообщении об ошибке ни слова о не нахождении .h файла.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Это слишком просто. Разумеется, я не забыл

Значит ключиками компилятора забыли указать -mmcu.

Добавлено after 2 minutes 4 seconds:
Если бы gcc не мог найти файла по #include, он бы ругнулся так:

и дальше не стал бы даже пытаться скомпилировать файл!
Значит проблема не в нахождении файла, а в его "содержимом". В данном случае avr/io.h содержит очень много #ifdef зависящих от модели МК, которая как раз передается ключиком -mmcu правильным. Если этого не сделать, файл для компилятора подключится, но окажется условно почти пустым. Поэтому и такие ошибки могут быть.

Добавлено after 2 minutes 41 second:
А, ну еще вариант конечно что -mmcu есть, но там указана модель МК в которой в принципе нет DDRB. Какая-нибудь тинька малоногая, к примеру.

Во, все. Подключил диск с вендой, скопировал библиотеки от вендового тулчейна. Так больше не ругается. Теперь иначе:

#define F_CPU должен стоять ДО #include <util/delay.h>.

благодарю, все работает.

Вот не надо тащить повсюду ардуинские привычки!
F_CPU должен быть описан в makefile ключом коспилятора, например,
-DF_CPU=12000000

COKPOWEHEU, какие нахрен ардуиновские привычки? Когда именно там его и задают в Makefile. Кто сказал, что "должен"?

NStorm, те самые, которые заставляют выбирать странные решения.
Представьте, что вы написали библиотеку - придется еще к ней в заголовочный файл вписывать частоту. А потом в один прекрасный момент забудете и будет у вас одна периферия считать что частота камня 1 МГц, а вторая - что 8 МГц.

COKPOWEHEU, а ничего, что именно в ардуине F_CPU вручную вписывать не надо, оно ключиком -D задается исходя из описалова в boards.txt? Я в курсе, что задавать это лучше в Makefile, только у ТС явно было уже задано в файле, исходя из ошибки.

И поэтому вы вместо того чтобы подсказать "как надо" подсказали "абы как лишь бы работало"?

И кто "скажет" make'у, что нужные дефайны требуется брать из некоего файла?
Более идеальным вариантом было бы Makefile генерировать cmake'ом, но для мелкоты и так сойдет.

Может есть какой-то правильный способ, я не знаю. Но мне не хочется все усложнять, работает и ладно, и так сойдет.

COKPOWEHEU, вот вам новые претенденты, до которых можно докопаться:



Система сборки IDE генерит Makefile на основе boards.txt. Как там правильнее, пойди расскажи на arduino.cc, это они придумали, а не мы.

make по умолчанию выполняет скрипт из makefile, ему ничего для этого говорить не надо.
Или вы о чем спрашивали-то? Кто в makefile будет частоту прописывать? Программист, очевидно. Так же как прочие ключи компиляции, имя камня и список исходников.

В общем, все не как у людей!