Кросс-компиляция NGINX (для случая GCC)

NGINX – это HTTP‑сервер и обратный прокси‑сервер, почтовый прокси‑сервер, а также TCP/UDP прокси‑сервер общего назначения, изначально написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных сайтов.

Однако кросс‑компиляция NGINX практически невозможна, поскольку разработанные Игорем Сысоевым скрипты конфигурирования исходного кода в большинстве случаев используют так называемую процедуру "Try Run".

Те кто знаком с утилитами Autoconf, Automake знают, что проверки необходимых параметров системы и кросс‑компилятора осуществляются различными процедурами, которые, в свою очередь, могут применять попытки сборки исходного кода (Try compile), компоновки объектных файлов (Try link) и, наконец, попытки запуска тестовых программ (Try Run).

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

Система сборки (подключение инструментов)

В этой статье мы рассмотрим, как подключить к системе сборки новый toolchain и использовать его в работе над проектом простого приложения для платы Longan Nano на базе микроконтроллера GD32VF103CBT6 от компании GigaDevice.

Система сборки создавалась для обеспечения параллельной сборки множества прошивок для линеек различных устройств, построенных на CPU с разными архитектурами. Однако если возникает необходимость, к ней можно подключать новые устройства. Именно этот процесс мы и рассмотрим.

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

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

Система сборки (примеры)

Система сборки Radix cross Linux достаточно подробно описана на странице Overview.

Здесь мы рассмотим новые аспекты использования системы сборки на простых примерах "Здравствуй, Мир!" для создания независимых пользовательских приложений с применением набора инструментариев Radix cross Linux.

Предыдущие версии системы сборки не подразумевали использования компиляторов Clang и Rust как основных cross-компиляторов. Однако современные реалии привели нас к необходимости использования собственных инструментариев LLVM и RUST, но не в качестве основных (поясним это далее).

Дело в том, что множество современных пакетов прикладных программ, помимо GCC, используют компиляторы языка Rust и набор LLVM. Разработчиков привлекает тот момент, что для поддержки множества архитектур целевых устройств достаточно установить одно средство, вместо использования нескольких инструментариев (Toolchain), собранных из исходного кода GCC.

Rust Custom Triplet

Целевые триплеты описывают платформу, на которой выполняется код, и являются основной концепцией системы сборки GNU. Обычно триплет содержит три поля: название семейства/модели CPU, поставщика и имя операционной системы. Кроме того, триплет может иметь дополнительное поле, отражающее Application Binary Interface (ABI), например: gnu, gnueabihf, gnu_ilp32.

Просмотреть целевой триплет текущей системы можно с помощью команды `gcc -dumpmachine':

bash-5.1$ gcc -dumpmachine
x86_64-slackware-linux

Если вы создаете новую систему или собственный GNU/Linux дистрибутив, у вас может возникнуть необходимость иметь собственный целевой триплет. Например, x86_64-radix-linux-gnu для CPU Intel или AMD.

MTA-STS

В данной статье мы рассмотрим настройку почтового сервера в части, касающейся политики SMTP MTA Strict Transport Security (MTA-STS). MTA-STS — стандарт, который был разработан для обеспечения использования TLS для подключений между почтовыми серверами. Крупные провайдеры почтовых служб, такие как Google, давно используют политику MTA-STS, описанную в стандарте RFC 8461. В нашей стране, среди первых оказалась служба Mail.ru, которая с 2020 года начала применять MTA-STS.

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