Скрытый потенциал ручных сборок

       

фрагмент make-файла, управляемого через переменные окружения


И вот торжественный момент! Все пиво выпито, все лошади запряжены, все опции настроены и мы с замираем сердца пишем "$make". Процесс сборки начался! Можно смело сушить траву, дербанить грибы и кайфовать, ибо компиляция длиться очень долгое время. Достаточно часто она прерывается с сообщением об ошибке. Что делать? Главное — не паниковать, а прочитать "ругательное" сообщение, перевести его на русский язык и проанализировать. Чаще всего программе не хватает какой-то библиотеки или заголовочного файла. Вообще-то, это должен быть выявить конфигуратор (если только он есть), но скачать недостающие компоненты при наличии интернета — не проблема. Знать бы только что именно надо скачать! К сожалению, далеко не всегда makefile сообщает "официальное" название библиотеки. Чаще всего нам просто говорят: отсутствует файл super-puper-zip.h или как его там. Не беда! Запускаем поисковик, вводим имя файла и смотрим — какому пакету он принадлежит и откуда его можно download'ть Так же неплохо сходить на форум поддержки или просто "закинуть" сообщение об ошибке в google. Ведь не одни же мы с ней столкнулись! А раз так, этот вопрос должен обсуждаться на различных форумах, которые наверняка дадут нам ответ. Если это не поможет — читаем документацию еще раз, обращая внимания на то, какие библиотеки и системные компоненты должны быть установлены или пробуем проиграться с опциями сборки, отключая все, что только можно отключить.

Хуже, когда сталкиваешься с грубыми ошибками самих разработчиков. Ведь make-файлы тоже люди пишут и далеко не на всех платформах их тестируют. Если так — попробуйте связаться с разработчиками (только хрен они вам ответ) или соберите программу на другой платформе (другим компилятором).

По умолчанию, программы, как правило, собираются с отладочной информацией, что существенно упрощает их отладку, но вместе с тем и увеличивает размер. Поскольку отладка чужих программ не входит в наши планы, отладочную информацию лучше убрать. Это можно сделать либо на стадии конфигурации: "$./configure --disable-debug", либо "вырезать" отладочную информацию из elf-файла "в живую", пропустив его через утилиту strip (входит в большинство UNIX-дистрибутивов). Но прежде, чем это делать, запустим программу file

и посмотрим на обстоятельства дел.

Вот, например, BOCHS:

$file bochs

bochs: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0,

dynamically linked (uses shared libs), not stripped



Содержание раздела