В работе рассматривается проблема эксплуатации кросс-компилятора на базе GCC и бинарных утилит для отечественных микропроцессоров в условиях разнообразия аппаратных платформ и дистрибутивов ОС Linux. Показано, что использование разделяемых библиотек (прежде всего glibc) и зависящих от конкретного дистрибутива сборок приводит к множеству несовместимостей и усложняет сопровождение. Предложена статическая «самодостаточная» инфраструктура для сборки кросс-компилятора, включающая компилятор, бинарные утилиты и набор библиотек, собранные с использованием mus - альтернативной реализации стандартной библиотеки языка C. Описана многошаговая процедура раскрутки (bootstrapping), позволяющая получить конечный комплект инструментов, не использующий разделяемые библиотеки и минимально зависящий от параметров конкретной системы (кроме разрядности процессора и интерфейса ядра Linux). Обсуждаются ограничения, связанные с отказом от разделяемых библиотек (поддержка LTO, санитайзеров), и возможные направления расширения инфраструктуры за счет включения дополнительных утилит для сборки, тестирования и отладки.
The paper addresses the problem of deploying a GCC- and binutils-based cross-compiler toolchain for domestic microprocessors in the context of a wide variety of hardware platforms and Linux distributions. It is shown that the use of shared libraries (primarily glibc) and distribution-specific builds leads to numerous incompatibilities and complicates maintenance. A static, self-contained infrastructure for building a cross-compiler is proposed, comprising the compiler, binary utilities, and a set of libraries built using musl – an alternative implementation of the C standard library. A multi-stage bootstrapping procedure is described that makes it possible to obtain a final toolchain which does not utilize shared libraries and only minimally dependent on the parameters of a specific system (apart from CPU word size and the Linux kernel interface). The limitations associated with abandoning shared libraries (LTO support, sanitizers) are discussed, as well as possible directions for extending the infrastructure by adding auxiliary tools for building, testing, and debugging.
The authors declare that there are no conflicts of interest present.