Мой вопрос: насколько безопасно на самом деле создать весь config.cache на реальном оборудовании и скопировать его на компьютер сборки?
Не очень безопасно.Хотя некоторые вещи, которые configure определяет, и кеши - это свойства целевой системы, я ожидаю, что многие из них будут build-system свойствами, такими как сведения о кросс-компиляции инструментария и кросс-библиотек, которые вы используете.Вы не можете надежно определить такие вещи, запустив configure на предполагаемой хост-системе.Я удивлен, что ваши усилия в этом направлении не столкнулись с большим количеством неприятностей, чем вы описываете.Это, вероятно, признак кросс-среды разработки, которая хорошо построена и -конфигурирована для своей цели.
Очевидно, установленные библиотеки должны быть одинаковыми
Возможно, это одна из наименьших проблем в вашем предложении.
но как быть с другими возможными проблемами - например, что если какой-либо инструмент (grep, python и т. д.) установлен в каком-то другом месте?Или он вообще отсутствует?
Да, если для сборки требуются те или иные инструменты, то эти детали являются некоторыми из свойств системы сборки, о которых я говорил.
Может ли ./configure обработать это (обновить недопустимое значение на проверенное)?
Нет.Если configure полагается на файл кэша, то дело в том, что он не перепроверяет кэшированные результаты.Скорее всего, вы могли бы создать такую вещь вручную для проекта, который вы поддерживаете сами, но это не очень выполнимо для стороннего кода, особенно если вы создаете несколько пакетов.
Я думаю, что итогявляется то, что кросс-компиляция является сложной задачей.Собственная компиляция должна быть предпочтительнее, если это возможно, даже если вам нужно делать это в виртуальной среде, а не в физической.И если вы можете успешно запустить скрипт проекта configure в целевой среде, то, вероятно, у вас есть собственная среда разработки, достаточная для такой собственной сборки.