Продолжаю рассказ про #MinGW #windows

Пожалуй, самая дичайшая дичь, с которой я столкнулся, это то, что #GNU #autohell позволяет настроить расширение для собранной статической библиотеки.

Настройка эта доступна не тому, кто запускает готовый configure, а запрятана где-то глубоко в настройках libtool/libtoolize (не спрашивайте, всратые гнутые скрипты, призванные облегчить линковку динамических библиотек под разные платформы). И, что самое удивительное, мейнтейнеры этой настройкой активно пользовались - у кого-то это lib, а у кого-то - a.

Поэтому я не могу пойти и параметризировать свои обвязки этим расширением, потому что его надо настраивать per project, а потом переделывать кучу моих скриптов, которые везде (до этого времени), полагали, что работают с .a файлами.

Я сделал несколько подходов к снаряду:

* Попробовал руками запатчить все проекты, чтобы свести все к .a файлам. Быстро задолбался и прекратил.

* Попробовал указать в качестве libtool стороннюю реализацию - https://github.com/midipix-project/slibtool Это работало удивительно хорошо, кроме тех случаев, когда не работало вовсе. Ну, например, у libtool есть режим "перелинковки" программ при их установке (наверное, для систем, в которых нет rpath). Зачем этот режим иногда срабатывал в случае статлинковки - неизвестно. Как отключить - неизвестно. А сторонняя реализация (совершенно справедливо!) это говно мамонта не поддерживает.

* В конце-концов, пришел к следующему - указал в качестве libtool один каноничный libtool на все проекты, который сам и подготовил заранее. Тут тоже есть свои косяки, потому что, наверняка, в этот каноничный libtool намешано знаний не только про target, но и про host, ну да хрен с ним. Пока этот вариант требует наименьшего вмешательства в сборочные скрипты.

Комбинация 2) и 3) позволила вообще не патчить исходные сборочные скрипты, и обойтись настройкой того, какой libtool использовать в проекте.