Назад | Перейти на главную страницу

Учимся компилировать вещи из исходников (в Unix / Linux / OSX)

Когда я устанавливаю программное обеспечение из пакетов (MacPorts / apt-get) везде, где только возможно, мне часто приходится компилировать пакеты из исходного кода. ./configure && make && sudo make install обычно достаточно, но иногда это не работает - а когда это не так, я часто застреваю. Это почти всегда так или иначе связано с зависимостями других библиотек.

Хочу узнать следующее:

Я готов вложить здесь немало времени и усилий - мне не обязательно нужны прямые ответы на вышеуказанные вопросы, я бы предпочел получить рекомендации по книгам / учебникам / часто задаваемым вопросам, которые я могу прочитать, которые дадут мне знания Мне нужно понимать, что на самом деле происходит, и, следовательно, решать проблемы самостоятельно.

Я прошу прощения за прямой ответ на все вопросы, но я не знаю каких-либо полезных руководств, часто задаваемых вопросов и т. Д. В основном то, что следует, - это 8 лет создания настольных приложений (которые я помогаю распространять), разочарование и поиск в Google:

1. Как мне понять, какие аргументы передать в ./configure?

Практика действительно. Autotools достаточно прост, поскольку он согласован. Но есть много всего, что использует cmake или пользовательские сценарии сборки. Как правило, вам не нужно ничего передавать для настройки, он должен выяснить, может ли ваша система создавать foo-tool или нет.

Все инструменты Configure и GNU ищут зависимости в /, / usr и / usr / local. Если вы устанавливаете что-нибудь в другом месте (что затрудняет установку зависимости с помощью MacPorts или Fink), вам нужно будет передать флаг для настройки или изменения среды оболочки, чтобы помочь инструментам GNU найти эти зависимости.

2. Как общие библиотеки работают в OS X / Linux - где они находятся в файловой системе, как ./configure && make находит их, что на самом деле происходит, когда они связаны с

В Linux они должны быть установлены по пути, который может найти динамический компоновщик, это определяется параметром LD_LIBRARY_PATH переменная окружения и содержимое /etc/ld.conf. На Mac это почти всегда одинаково для большинства программного обеспечения с открытым исходным кодом (если это не проект Xcode). За исключением переменной env DYLD_LIBRARY_PATH вместо.

Существует путь по умолчанию, по которому компоновщик ищет библиотеки. Это / lib: / usr / lib: / usr / local / lib

Вы можете дополнить это, используя переменную CPATH, CFLAGS или любое количество других переменных среды (что удобно). Предлагаю такие CFLAGS:

экспорт CFLAGS = "$ CFLAGS -L / новый / путь"

Параметр -L добавляет к пути ссылки.

Современные материалы используют инструмент pkg-config. Современные компоненты, которые вы устанавливаете, также устанавливают файл .pc, который описывает библиотеку, ее местонахождение и ссылки на нее. Это может облегчить жизнь. Но он не поставляется с OS X 10.5, поэтому вам также придется установить его. Также многие базовые депы не поддерживают его.

Акт связывания - это просто «разрешить эту функцию во время выполнения», на самом деле это большая таблица строк.

3. Каковы фактические различия между общей и статически связанной библиотекой? Почему я не могу просто статически связать все (оперативная память и дисковое пространство сейчас дешевы) и, следовательно, избежать странных конфликтов версий библиотеки?

Когда вы связываете файл статической библиотеки, код становится частью вашего приложения. Это как если бы для этой библиотеки был один гигантский файл .c, и вы скомпилировали его в свое приложение.

Динамические библиотеки имеют одинаковый код, но когда приложение запускается, код загружается в приложение во время выполнения (упрощенное объяснение).

Вы можете статически связать все, однако, к сожалению, вряд ли какие-либо системы сборки позволяют это легко сделать. Вам придется вручную редактировать системные файлы сборки (например, Makefile.am или CMakeLists.txt). Однако это, вероятно, стоит изучить, если вы регулярно устанавливаете вещи, для которых требуются разные версии библиотек, и вам сложно установить зависимости параллельно.

Уловка заключается в том, чтобы изменить строку ссылки с -lfoo на -l / path / на / static / foo.a

Наверное можно найти и заменить. После этого убедитесь, что инструмент не ссылается на .so или dylib, используя ldd foo или otool -L foo.

Другая проблема заключается в том, что не все библиотеки компилируются в статические библиотеки. Многие так и делают. Но тогда MacPorts или Debian, возможно, решили не выпускать его.

4. Как узнать, какие библиотеки я установил и какие версии?

Если у вас есть файлы pkg-config для этих библиотек, это просто:

pkg-config --list-все

В противном случае вам часто будет нелегко. У dylib может быть soname (например, foo.0.1.dylib, soname 0.1), которое совпадает с версией библиотеки. Однако этого не требуется. Soname - это функция двоичной вычислимости, вы должны изменить большую часть soname, если вы измените формат функций в библиотеке. Так что вы можете получить, например. версия 14.0.5 soname для библиотеки 2.0. Хотя такое бывает нечасто.

Я был разочарован подобными вещами и разработал решение для этого на Mac, и я расскажу об этом позже.

5. Как я могу установить более одной версии библиотеки, не нарушая мою обычную систему?

Мое решение здесь: http://github.com/mxcl/homebrew/

Мне нравится установка из исходников, и мне нужен инструмент, который упростил бы это, но с некоторым управлением пакетами. Итак, с помощью Homebrew я создаю, например. wget из исходников, но обязательно установите специальный префикс:

/usr/local/Cellar/wget/1.1.4

Затем я использую инструмент homebrew для символической ссылки на все это в / usr / local, поэтому у меня все еще есть / usr / local / bin / wget и /usr/local/lib/libwget.dylib

Позже, если мне понадобится другая версия wget, я могу установить ее параллельно и просто изменить версию, которая связана с деревом / usr / local.

6. Если я устанавливаю что-то из исходного кода в систему, которая иначе управляется с помощью пакетов, каков самый чистый способ сделать это?

Я считаю, что способ Homebrew самый чистый, поэтому используйте его или сделайте аналогичный. Установите в / usr / local / pkgs / name / version и оставьте символическую ссылку или жесткую ссылку в.

Используйте / usr / local. Каждый существующий инструмент сборки ищет там зависимости и заголовки. Ваша жизнь будет много Полегче.

7. Предполагая, что мне удастся скомпилировать что-то сложное из исходного кода, как я могу затем упаковать это, чтобы другим людям не приходилось прыгать через одни и те же обручи? Особенно на OS X ....

Если у него нет зависимостей, вы можете заархивировать каталог сборки и передать его кому-то другому, который затем сможет выполнить «make install». Однако вы можете сделать это надежно только для тех же самых версий OS X. В Linux это, вероятно, будет работать для аналогичного Linux (например, Ubuntu) с той же версией ядра и дополнительной версией libc.

Причина, по которой распространять двоичные файлы в Unix непросто, заключается в совместимости двоичных файлов. Люди GNU и все остальные часто меняют свои двоичные интерфейсы.

В основном не распространяйте двоичные файлы. Все, вероятно, сломается очень странным образом.

На Mac лучший вариант - создать пакет macports. Все используют macports. В Linux существует так много различных систем сборки и комбинаций, что я не думаю, что есть лучший совет, чем написать запись в блоге о том, как вам удалось собрать инструмент x в странной конфигурации y.

Если вы сделаете описание пакета (для macports или homebrew), то любой сможет установить этот пакет, и это также решит проблемы с зависимостями. Однако это часто бывает непросто, и также нелегко включить ваш рецепт macports в главное дерево macports. Также macports не поддерживает экзотические типы установки, они предлагают один выбор для всех пакетов.

Одна из моих будущих целей с Homebrew - сделать возможным щелчок по ссылке на веб-сайте (например, homebrew: // blah, и он загрузит этот скрипт Ruby, установит deps для этого пакета, а затем создаст приложение. Но да, еще не сделано, но не слишком сложно, учитывая выбранный мной дизайн.

8. Какие инструменты командной строки мне нужно освоить, чтобы хорошо разбираться в этом? Такие вещи, как otool, pkg-config и т. Д.

otool действительно пригодится только потом. Он сообщает вам, на что ссылается созданный двоичный файл. Когда вы выясняете зависимости инструмента, который вам нужно создать, это бесполезно. То же самое и с pkg-config, так как вы уже установили зависимость, прежде чем сможете ее использовать.

Моя цепочка инструментов: прочтите файлы README и INSTALL и выполните команду configure --help. Посмотрите результат сборки, чтобы убедиться, что он нормальный. Проанализируйте все ошибки сборки. Может в будущем спросите на serverfault :)

Это огромная тема, поэтому давайте начнем с общих библиотек в Linux (ELF в Linux и Mach-O в OS X). У Ульриха Дреппера есть хороший введение в написание DSO (динамические общие объекты), который охватывает некоторую историю общих библиотек в Linux, доступных здесь, в том числе, почему они важны

Ульрих также описывает, почему статические ссылки считаются вредными один из ключевых моментов здесь - обновления безопасности. Переполнение буфера в общей библиотеке (например, zlib), которая сильно связана статически, может вызвать огромные накладные расходы для дистрибутивов - это произошло с zlib 1.1.3 (Консультации Red Hat)

ELF

Справочная страница компоновщика ld.so

man ld.so 

объясняет основные пути и файлы, участвующие в динамической компоновке во время выполнения. В современных системах Linux вы увидите дополнительные пути, добавленные через /etc/ld.so.conf.d/, добавленные обычно через глобус, включенный в /etc/ld.so.conf.

Если вы хотите увидеть, что доступно динамически через вашу конфигурацию ld.so, вы можете запустить

ldconfig -v -N -X

Чтение руководства по DSO должно дать вам хороший базовый уровень знаний, чтобы затем понять, как эти принципы применимы к Mach-O в OS X.

Мачо

В OS X двоичный формат - Mach-O. Документация по локальной системе для компоновщика:

man dyld

В Документация формата Mach доступно от Apple

Инструменты сборки UNIX

Общее configure, make, make install процесс обычно предоставляется автоинструментами GNU, которые имеют онлайн-книга который охватывает некоторую историю разделения конфигурации / сборки и инструментальной цепочки GNU. Autoconf использует тесты для определения доступности функций в целевой системе сборки, он использует Макроязык M4 управлять этим. Automake это в основном метод создания шаблонов для Makefile, шаблон обычно называется Makefile.am, который выводит Makefile.in, который вывод autoconf (скрипт настройки) преобразуется в Makefile.

В GNU привет Программа служит хорошим примером для понимания цепочки инструментов GNU, а руководство включает документацию по autotools.

Саймон! Я знаю, как ты себя чувствуешь; Я тоже боролся с этой частью изучения Linux. Основываясь на собственном опыте, я написал руководство по некоторым вопросам, которые вы рассматриваете (в основном, как справочник для себя!): http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html. Думаю, вы оцените мое замечание о том, насколько просто создавать / устанавливать приложения Python. :)

Надеюсь, это поможет! И счастливой компиляции.

Тим Джонс


Сборка / установка приложения из исходного кода в Ubuntu Linux

В то время как репозитории Ubuntu полны отличных приложений, в какой-то момент вы обязательно столкнетесь с тем «обязательным» инструментом, которого нет в репозиториях (или не имеет пакета Debian), или вам понадобится версия новее, чем в репозиториях. Чем ты занимаешься? Что ж, вам нужно собрать приложение из исходников! Не волнуйтесь, это действительно не так сложно, как кажется. Вот несколько советов, основанных на моем опыте перехода из любительского уровня! (Хотя я использую Ubuntu для этого примера, общие концепции должны быть применимы к большинству любых дистрибутивов Unix / Linux, таких как Fedora, и даже к платформе Cygwin в Windows.)

Базовый процесс сборки (компиляции) большинства приложений из исходных текстов следует следующей последовательности: настройка -> компиляция -> установка. Типичные команды Unix / Linux для этого: config -> make -> make install. В некоторых случаях вы даже найдете веб-страницы, которые показывают, что все это можно объединить в одну команду:

$ config && make && make install

Конечно, эта команда предполагает, что ни на одном из этих шагов нет проблем. Вот где самое интересное!

Начиная

Если вы раньше не компилировали приложение из исходного кода в своей системе, вам, вероятно, потребуется настроить его с помощью некоторых общих инструментов разработки, таких как gcc набор компиляторов, некоторые общие файлы заголовков (воспринимайте это как код, который уже был написан кем-то другим и который используется программой, которую вы устанавливаете) и инструмент make. К счастью, в Ubuntu есть метапакет под названием build-essential который установит это. Чтобы установить его (или просто убедиться, что он у вас уже есть!), Запустите эту команду в терминале:

$ sudo apt-get install build-essential

Теперь, когда у вас есть базовая настройка, загрузите исходные файлы приложения и сохраните их в каталог, для которого у вас есть разрешения на чтение / запись, например в ваш «домашний» каталог. Как правило, они находятся в архивном файле с расширением файла .tar.gz или .tar.bz2. В .tar просто означает, что это «ленточный архив», который представляет собой группу файлов, сохраняющую их относительную структуру каталогов. В .gz означает gzip (GNU zip), популярный формат сжатия для Unix / Linux. Точно так же .bz2 означает bzip2, более новый формат сжатия, обеспечивающий более высокое сжатие (меньший размер сжатого файла), чем gzip.

После загрузки исходного файла откройте окно терминала (Системный терминал из меню Ubuntu) и перейдите в каталог, в котором вы сохранили файл. (Я буду использовать ~/download в этом примере. Здесь '~' - это ярлык для вашего "домашнего" каталога.) Используйте команду tar для извлечения файлов из загруженного файла архива:

Если ваш файл представляет собой архив gzip (например, заканчивается на .tar.gz) используйте команду:

            $ tar -zxvf filename.tar.gz

Если ваш файл представляет собой архив bzip2 (например, заканчивается на .tar.bz2) используйте команду:

            $ tar -jxvf filename.tar.gz

Совет: если вы не хотите запоминать все параметры командной строки для извлечения архивов, я рекомендую приобрести одну (или обе) из этих утилит: dtrx (моя любимая!) Или deco (более популярная). С любой из этих утилит вы просто вводите имя утилиты (dtrx или deco) и имя файла, а она делает все остальное. Оба они «знают», как работать с любым форматом архивов, с которым вы, вероятно, столкнетесь, и отлично справляются с ошибками.

При сборке из исходного кода вы, вероятно, столкнетесь с двумя типичными типами ошибок:

  1. Ошибки конфигурации возникают, когда вы запускаете сценарий конфигурации (обычно называемый config или configure) для создания файла makefile, специфичного для вашей установки.
  2. Ошибки компилятора возникают, когда вы запускаете команду make (после того, как make-файл был сгенерирован), и компилятор не может найти некоторый код, который ему нужен.

Мы рассмотрим каждую из них и обсудим, как их решить.

Конфигурация и ошибки конфигурации

После того, как вы извлекли файл архива исходного кода, в терминале вы должны перейти в каталог, содержащий извлеченные файлы. Как правило, это имя каталога будет таким же, как имя файла (без .tar.gz или .tar.bz2 расширение). Однако иногда имя каталога - это просто имя приложения без какой-либо информации о версии.

В исходном каталоге найдите README файл и / или INSTALL файл (или что-то с похожими именами). Эти файлы обычно содержат полезную информацию о том, как собрать / скомпилировать приложение и установить его, включая информацию о зависимостях. «Зависимости» - это просто причудливое название для других компонентов или библиотек, необходимых для успешной компиляции.

После того, как вы прочитали README и / или INSTALL файл (и, надеюсь, просмотрел любую соответствующую онлайн-документацию по приложению), найдите исполняемый файл (для которого установлено разрешение "x") файл с именем config или configure. Иногда файл может иметь расширение, например .sh (например., config.sh). Обычно это сценарий оболочки, который запускает некоторые другие утилиты, чтобы подтвердить, что у вас есть «нормальная» среда для компиляции. Другими словами, он проверит, установлено ли у вас все необходимое.

Совет: если это приложение на основе Python, вместо файла конфигурации вы должны найти файл с именем setup.py. Приложения Python обычно очень просты в установке. Чтобы установить это приложение как root (например, поместите sudo перед следующей командой в Ubuntu), выполните эту команду:

    $ python setup.py install

Это должно быть все, что вам нужно сделать. Вы можете пропустить оставшуюся часть этого руководства и перейти непосредственно к использованию вашего приложения.

Запустите сценарий конфигурации в терминале. Как правило, вы можете (и должны!) Запускать сценарий конфигурации под своей учетной записью обычного пользователя.

$ ./config

Скрипт отобразит несколько сообщений, чтобы дать вам представление о том, что он делает. Часто сценарий дает указание на успех или неудачу, а в случае неудачи - некоторую информацию о причине отказа. Если вы не получаете сообщений об ошибках, то обычно можно предположить, что все прошло нормально.

Если вы не найдете скрипта, который выглядел бы как скрипт конфигурации, это обычно означает, что приложение очень простое и не зависит от платформы. Это означает, что вы можете просто перейти к шагу сборки / компиляции ниже, потому что предоставленный Makefile должен работать в любой системе.

Пример

В этом руководстве я собираюсь использовать текстовую программу чтения RSS под названием Newsbeuter в качестве примера типов ошибок, с которыми вы можете столкнуться при создании приложения. Для Newsbeuter имя сценария конфигурации: config.sh. В моей системе, когда я бегу config.sh, возникают следующие ошибки:

tester@sitlabcpu22:~/download/newsbeuter-1.3$ ./config.sh
Checking for package sqlite3... not found

You need package sqlite3 in order to compile this program.
Please make sure it is installed.

Проведя небольшое исследование, я обнаружил, что на самом деле sqlite3 приложение было установлено. Однако, поскольку я пытаюсь построить из исходного кода, это подсказка о том, что config.sh на самом деле ищет библиотеки для разработки (заголовки) для sqlite3. В Ubuntu с большинством пакетов связан пакет-аналог для разработки, заканчивающийся на -dev. (Другие платформы, такие как Fedora, часто используют суффикс пакета -devel для пакетов разработки.)

Чтобы найти подходящий пакет для sqlite3 пакет разработки, мы можем использовать apt-cache утилита в Ubuntu (и аналогично yum утилита в Fedora):

tester@sitlabcpu22:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite

Эта команда возвращает довольно большой список результатов, поэтому нам нужно проделать небольшую детективную работу, чтобы определить, какой пакет является подходящим. В этом случае соответствующий пакет оказывается libsqlite3-dev. Обратите внимание, что иногда пакет, который мы ищем, будет иметь lib префикс, вместо того же имени пакета плюс -dev. Это потому, что иногда мы просто ищем общую библиотеку, которая может использоваться множеством разных приложений. Установить libsqlite3-dev, запустите в терминале стандартную команду установки apt-get:

tester@sitlabcpu22:~/download/newsbeuter-1.3$ sudo apt-get install libsqlite3-dev

Теперь нам нужно бежать config.sh еще раз, чтобы убедиться, что мы решили эту проблему с зависимостями и что у нас больше нет проблем с зависимостями. (Хотя я не буду показывать его здесь, в случае с Newsbeuter мне также пришлось установить libcurl4-openssl-dev пакет.) Кроме того, если вы устанавливаете пакет разработки (например, libsqlite3-dev) и связанный пакет приложения (например, sqlite3) еще не установлен, большинство систем автоматически установят связанный пакет приложения одновременно.

Когда конфигурация выполняется успешно, результатом будет создание одного или нескольких файлов make. Эти файлы обычно называются Makefile (помните, что регистр имени файла имеет значение в Unix / Linux!). Если пакет сборки включает подкаталоги, например srcи т. д., каждый из этих подкаталогов будет содержать Makefile, также.

Ошибки сборки и компиляции

Теперь мы готовы к компиляции приложения. Это часто называют строительством, и это название заимствовано из реального процесса создания чего-либо. Различные «части» приложения, которые обычно представляют собой несколько файлов с исходным кодом, объединяются вместе для формирования общего приложения. Утилита make управляет процессом сборки и вызывает другие приложения, такие как компилятор и компоновщик, для фактического выполнения работы. В большинстве случаев вы просто запускаете make (со своей учетной записью обычного пользователя) из каталога, в котором вы запускали конфигурацию. (В некоторых случаях, например, при компиляции приложений, написанных с использованием библиотеки Qt, вам потребуется вместо этого запустить другое приложение-оболочку, такое как qmake. Опять же, всегда проверяйте README и / или INSTALL документы для деталей.)

Как и в случае с приведенным выше сценарием конфигурации, когда вы запускаете make (или аналогичную утилиту) в терминале, он будет отображать некоторые сообщения о том, что выполняется, а также любые предупреждения и ошибки. Как правило, вы можете игнорировать предупреждения, поскольку они в основном предназначены для разработчиков приложения и говорят им о том, что некоторые стандартные методы нарушаются. Обычно эти предупреждения не влияют на работу приложения. С другой стороны, необходимо иметь дело с ошибками компилятора. С Newsbeuter, когда я запускал make, какое-то время все шло хорошо, но потом я получил ошибку:

tester@sitlabcpu22:~/download/newsbeuter-1.3$ make
...
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/configparser.o -c src/configparser.cpp
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/colormanager.o -c src/colormanager.cpp
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:5:18: error: stfl.h: No such file or directory
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:33: error: ISO C++ forbids declaration of \u2018stfl_form\u2019 with no type
./include/stflpp.h:33: error: expected \u2018;\u2019 before \u2018*\u2019 token
./include/stflpp.h:34: error: ISO C++ forbids declaration of \u2018stfl_ipool\u2019 with no type
./include/stflpp.h:34: error: expected \u2018;\u2019 before \u2018*\u2019 token
make: *** [src/colormanager.o] Error 1

Процесс make остановится, как только будет обнаружена первая ошибка. Обработка ошибок компилятора иногда может быть сложной задачей. Вы должны посмотреть на ошибки, чтобы понять суть проблемы. Как правило, проблема заключается в том, что некоторые файлы заголовков, которые обычно имеют расширение .h или .hpp, не хватает. В случае вышеуказанной ошибки ясно (или должно быть!), Что проблема в том, что stfl.h заголовочный файл не может быть найден. Как показано в этом примере, вы хотите просмотреть первые строки сообщения об ошибке и спуститься вниз, чтобы найти основную причину проблемы.

Посмотрев документацию Newsbeuter (которую я должен был сделать до того, как начать, но тогда эта часть учебника не будет иметь большого смысла!), Я обнаружил, что для нее требуется сторонняя библиотека под названием STFL. Итак, что нам делать в этом случае? Что ж, мы, по сути, повторяем тот же процесс для этой необходимой библиотеки: получаем библиотеку и выполняем для нее процесс настройки-сборки-установки, а затем возобновляем сборку желаемого приложения. Например, в случае с STFL мне пришлось установить libncursesw5-dev пакет для правильной сборки. (Обычно нет необходимости повторять шаг настройки в нашем исходном приложении после установки другого необходимого приложения, но это также никогда не повредит.)

После успешной установки инструментария STFL процесс создания Newsbeuter прошел успешно. Процесс make обычно продолжается с того места, где он остановился (в момент возникновения ошибки). Таким образом, любые файлы, которые уже были успешно скомпилированы, не будут перекомпилированы. Если вы хотите все перекомпилировать, вы можете запустить make clean all, чтобы удалить все скомпилированные объекты, а затем снова запустить make.

Установка

После успешного завершения процесса сборки вы готовы к установке приложения. В большинстве случаев для установки приложения в общие области файловой системы (например, /usr/bin или /usr/share/binи т. д.), вам нужно будет запустить установку от имени пользователя root. Установка действительно самый простой шаг во всем процессе. Для установки в терминале запустите:

$ make install

Проверьте результат этого процесса на наличие ошибок. Если все прошло успешно, вы сможете запустить команду с именем в терминале, и она запустится. (Добавьте & в конец командной строки, если это приложение с графическим интерфейсом, иначе вы не сможете использовать сеанс терминала, пока приложение не завершит работу.)

Когда вы создаете приложение из исходного кода, оно обычно не добавляет значок или ярлык в меню графического интерфейса в Ubuntu. Вам нужно будет добавить это вручную.

И это в основном процесс, хотя и потенциально повторяющийся, для создания и установки приложения из исходного кода в Ubuntu. После того, как вы проделаете это всего несколько раз, это станет для вас второй натурой!

Что ж, ./configure --help предоставит вам много информации для файлов конфигурации, сгенерированных автоинструментами GNU. Большинство из них сводится к --with / - без включения функций (они могут принимать дополнительный параметр, например «shared», чтобы указать, где найти библиотеку).

Другими важными из них являются --prefix (который по умолчанию - / usr / local / большую часть времени), чтобы указать, куда устанавливать (если вы создаете пакеты, вы обычно хотите это как --prefix = / usr или, возможно, --prefix = / opt / YourPackage).

В Linux, / lib, / usr / lib и / usr / local / lib обычно ищутся в моем gcc и включаются в конфигурацию ldconfig по умолчанию. Если у вас нет веской причины, ваши библиотеки нужны именно здесь. Однако /etc/ld.so.conf может содержать дополнительные записи.

configure и make найти их, просто попытавшись запустить "gcc -l" и проверив, нет ли ошибок. Вы можете добавить «-L» к параметру CFLAGS, чтобы добавить дополнительные пути для поиска.

У вас может быть установлено несколько версий, и программное обеспечение, связанное с более старой версией, останется связанным с ней (запустите ldd, чтобы узнать привязку в Linux), но новые компиляции обычно нацелены на последнюю версию динамической библиотеки в вашей системе.

Большинство программ предполагает наличие динамических библиотек, особенно если они используют libtool, поэтому вы можете обнаружить, что нетривиальные приложения не собираются правильно статически.

ls -l - лучший выбор для поиска установленных библиотек.

И вот где у меня нет информации; как хорошо играть с пакетами: не знаю. По возможности я стараюсь упаковывать вещи в пакет, чтобы избежать проблем.

«Как мне определить, какие аргументы передать в ./configure?»

обычно: ./configure --help сообщит вам, что вы хотите там.

«Как я могу узнать, какие библиотеки я установил и какие версии?»

Это зависит от системы. Один из способов - просто сделать find /|grep libname|less поскольку обычно файлы библиотеки имеют версию в имени файла.

«Как я могу установить более одной версии библиотеки, не нарушая мою обычную систему?»

Опять же, зависит от системы и библиотеки. sudo make altinstall создаст для вас версионное имя. Однако файлы библиотеки обычно сами версии. Имейте в виду, однако; поскольку версии часто создают символические ссылки на «нормализованное» имя, это может сломать ситуацию.

«Если я устанавливаю что-то из исходного кода в систему, которая иначе управляется с помощью пакетов, каков самый чистый способ сделать это?»

Используя параметры --prefix в ./configure и поместив их где-нибудь в /opt это хорошая практика.

Отказ от ответственности: Я ни в коем случае не эксперт, но я использую Linux более 5 лет из строки cmd (Slackware, CentOS, redhat, ubuntu, разное, другие и OS X).

Чтобы немного ответить на ваш вопрос, на днях я нашел хороший способ узнать, какие библиотеки вы установили и какие версии (это в Linux Debian, поэтому он должен работать и с другими версиями).

dpkg --list

У вас должен получиться действительно длинный список с такими выводами

ii  libssl0.9.8    0.9.8c-4etch5  SSL shared libraries
ii  libssp0        4.1.1-21       GCC stack smashing protection library
ii  libstdc++5     3.3.6-15       The GNU Standard C++ Library v3
ii  libstdc++5-3.3 3.3.6-15       The GNU Standard C++ Library v3 (development
ii  libstdc++6     4.1.1-21       The GNU Standard C++ Library v3

Саймон,

1.) ./configure --help предоставляет большой объем информации. Предлагаю это проверить. Обычно в нем есть опции для компиляции статических / динамически подключаемых библиотек, когда это необходимо.

2.) Библиотеки находятся в пути динамического компоновщика. Обычно это устанавливается в /etc/ld.so.conf. Компоновщик ищет соответствующие библиотеки во многом аналогично переменной среды PATH, соответствующей первой найденной.

3.) Это обычно приводит к проблемам, так как вам нужно все перекомпилировать при изменении версии библиотеки. Если вы немного поищете, вы, вероятно, найдете массу причин, по которым статические ссылки - плохая идея. Я не делал этого так давно, что не могу здесь подробно остановиться.

4.) Это немного сложно. Вам нужно проверить путь к вашей библиотеке, чтобы быть абсолютно уверенным. Библиотеки обычно имеют символическую ссылку на установленную версию.

например libssh2.so.1 -> libssh2.so.1.0.0

Обычно люди управляют устанавливаемыми ими библиотеками и программами либо путем развертывания собственных пакетов debian, либо с помощью какой-либо другой техники. Я управляю установленным ПО с помощью stow (http://www.gnu.org/software/stow/), который очень прост и устанавливает библиотеку с помощью символических ссылок. Мне это проще, поскольку мне не нужно собирать / устанавливать / тестировать пакет deb / rpm.

5.) В каталоги библиотек можно установить несколько версий библиотек. Библиотеки, связанные с исполняемыми файлами, останутся связанными с версиями, с которыми они были связаны. запуск ldd для исполняемого файла сообщит вам, с какими библиотеками связан исполняемый файл.

6.) Как я уже упоминал ранее, развертывание собственных пакетов debian или использование stow, вероятно, является самым чистым решением.

7.) Я не могу говорить о Mac OSX, но для Linux лучше всего подходит система упаковки дистрибутива.

8.) Вероятно, многие разочарования будут решены, если использовать ldd и выяснить, с какой версией что-то связано или какая библиотека, связанная с исполняемым файлом, не может быть найдена. pkg-config вам очень поможет, но только для программного обеспечения, которое его использует. Он не входит в стандартную систему сборки автоинструментов, хотя сейчас популярен.

Статические библиотеки - не лучшая идея - если вам нужно обновить библиотеку (например, чтобы исправить проблему с безопасностью), вам нужно будет перекомпилировать все, зависящее от этой библиотеки.

Мне не нравится идея «make install», которая потенциально может испортить мою систему, но, как говорили другие, обычно намного проще устанавливать что-то в / usr / local вместо использования --prefix для установки в другом месте. Итак, я назначил / usr / local своему обычному (непривилегированному) пользователю. Таким образом, "make install" почти наверняка не повредит важные системные файлы. (Очевидно, что это не будет работать в многопользовательских системах. Однако это отлично подходит для виртуальных серверов.)

Хотя этого явно не было в вашем списке вопросов, в предисловии вы упоминаете:

./configure && make && sudo make install обычно достаточно, но иногда это не работает - а когда это не так, я часто застреваю.

Когда я застряну в Debian или Ubuntu, я буду использовать auto-apt, который автоматически установит пакеты, содержащие файлы, которые configure не может найти.

Видеть:

Еще один инструмент, который может вам пригодиться, - это CheckInstall, он добавляет приложения, установленные с make install в ваш список установленных пакетов: https://help.ubuntu.com/community/CheckInstall

Для OS X:

  • Как мне понять, какие аргументы передать в ./configure?

./configure --help

  • Каковы фактические различия между общей и статически связанной библиотекой? Почему я не могу просто статически связать все (оперативная память и дисковое пространство сейчас дешевы) и, следовательно, избежать странных конфликтов версий библиотеки?

Использование разделяемых библиотек позволяет обновлять библиотеку без перекомпиляции всего, что ее использует.

  • Как общие библиотеки работают в OS X / Linux - где они находятся в файловой системе, как ./configure && make находит их, что на самом деле происходит, когда они связаны с

Системные библиотеки находятся в / usr / lib.

Библиотеки, которые вы компилируете сами, находятся в / usr / local / lib (/ usr / local является флагом --prefix по умолчанию для ./configure).

Переменные среды DYLD_FALLBACK_LIBRARY_PATH и LD_LIBRARY_PATH позволяют указать, в каких папках искать, поэтому / usr / local / lib должен быть в начале списка.

  • Как я могу установить более одной версии библиотеки, не нарушая мою обычную систему?

Установите все в / usr / local - с указанными выше переменными среды версия в / usr / local / lib имеет приоритет над версией в / usr / lib в вашей среде.

  • Если я устанавливаю что-то из исходного кода в систему, которая иначе управляется с помощью пакетов, каков самый чистый способ сделать это?

Установите в / usr / local. В Ubuntu я сначала пытаюсь использовать checkinstall, чтобы создать пакет deb.

  • Предполагая, что мне удастся скомпилировать что-то сложное из исходного кода, как я могу затем упаковать это, чтобы другим людям не приходилось прыгать через одни и те же обручи? Особенно на OS X ....

Я бы сказал, что документируйте шаги компиляции в блоге.