Крос-компіляція cygwin - mingw - Від ідеї до профіту
Крос-компіляція cygwin → mingw
Якийсь час тому я почав свій кросплатформовий проект. Оскільки сиджу я в основному за Windows, то для компіляції зазвичай використовую cygwin, а для збирання білдів для тестерів під cygwin живе i686-w64-mingw. Все було добре, але прийшла пора, і для виведення пари фраз тексту я вирішив підключити до проекту libfreetype. При компіляції на cygwin проблем немає - адже в репозиторії є відповідний пакет, а для mingw, природно, доведеться збирати лібу самому.
Щоб до мене не було питань, я вирішив підключати лібу динамічно, а всі її залежності (щоб не тягнути купу лівих файлів) стати статично лінкувати. Про мій гіркий досвід я тут і розповім.
Спочатку трохи теорії. У будь-якому проекті на autotools крос-компіляція легко реалізується за допомогою двох основних параметрів:
- --build — вказує ім'я середовища, в якому ми компілюємо
- --host — вказує ім'я середовища, в якому результат запускатиметься
Важливо не плутати ці ключі, встановлювати обидва в mingw32 теж не найкращий варіант (адже він і справді повірить, що ви працюєте в MSYS).
У результаті рядок конфігурації буде виглядати так:
Але не поспішайте її виконувати.
freetype має дві залежності: libz і libbz2, - їх статичні версії для mingw ми вже зібрали раніше. І якщо зараз спробувати скомпілювати freetype, libtool на них свариться: мовляв, ми тут динамічні бібліотеки компілює, нефіг тут статику мені пхати. У чомусь він правий, але нам все ж таки доведеться якось обійти це обмеження. Найпростіше рішення — передати ключі бібліотек безпосередньо лінкеру:
Запускаємо складання - все чудово! Тільки ... чомусь в експорті dll не тільки freetype, а й libz і libbz2! З чогоб це?
Причина у ключі -no-undefined . Є два способи додати функції експорту: спеціальні атрибути у потрібних функцій і ключ -no-undefined , тоді всі функції будуть експортуватися. Як із цим боротися? На допомогу приходить -export-symbols, щоб його активувати, виконаємо: