Вопрос: Изучение компиляции вещей из исходного кода (в Unix / Linux / OSX)


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

Я хотел бы узнать следующее:

  • Как я могу выяснить, какие аргументы следует передать ./configure?
  • Как совместно используемые библиотеки работают под OS X / Linux - где они живут в файловой системе, как ./configure && make находит их, что на самом деле происходит, когда они связаны с
  • Каковы фактические различия между общей и статически связанной библиотекой? Почему я не могу просто статически связать все (в наши дни RAM и дисковое пространство дешево) и, следовательно, избежать странных конфликтов версий библиотеки?
  • Как узнать, какие библиотеки я установил и какие версии?
  • Как я могу установить несколько версий библиотеки без нарушения нормальной работы системы?
  • Если я я устанавливая материал из источника в системе, которая управляется иным образом с использованием пакетов, каков самый чистый способ сделать это?
  • Предполагая, что мне удается что-то скомпилировать из источника, как я могу упаковать его, чтобы другим людям не приходилось перепрыгивать через те же самые обручи? В частности, на OS X ....
  • Какие инструменты командной строки мне нужно освоить, чтобы хорошо разбираться в этом? Такие вещи, как otool, pkg-config и т. Д.

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


45
2017-07-27 08:48


Источник




Ответы:


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

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

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

Настроить и инструменты 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 так:

export CFLAGS = "$ CFLAGS -L / новый / путь"

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

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

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

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

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

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

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

Трюк состоит в том, чтобы изменить линию линии от -lfoo до -l / path / to / static / foo.a

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

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

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

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

pkg-config --list-all

В противном случае вы часто не можете легко. У dylib может быть soname (то есть foo.0.1.dylib, soname равно 0,1), что совпадает с версией библиотеки. Однако это не требуется. Soname - это функция двоичной вычисляемости, вы должны задействовать основную часть soname, если вы измените формат функций в библиотеке. Таким образом, вы можете получить, например. версии 14.0.5 для библиотеки 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 ....

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

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

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

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

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

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

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

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

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


38
2017-07-27 13:08



Интересно, что Homebrew очень похож на Portage (менеджер пакетов от Gentoo Linux). Звучит как приятная работа. - David Z


Это огромная тема, поэтому давайте начнем с разделяемых библиотек в 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/, добавленные обычно через glob, включенные в /etc/ld.so.conf.

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

ldconfig -v -N -X

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

Мачо

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

man dyld

Документация формата Маха можно приобрести у Apple

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

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

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


11
2017-07-27 09:18





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

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

Тим Джонс


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

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

Основной процесс построения (компиляции) большинства приложений из источника следует этой последовательности: configure -> compile -> install. Типичными командами 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.

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

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

            $ tar -zxvf filename.tar.gz

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

            $ tar -jxvf filename.tar.gz

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

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

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

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

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

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

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

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

Совет. Если это Python-based   приложение вместо файла конфигурации,   вы должны найти файл с именем setup.py,   Приложения Python, как правило, очень   простой в установке. Чтобы установить это   приложение, как root (например, put 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 процесс make для Newsbeuter успешно запущен. Процесс make обычно поднимается там, где он уходит (в точке ошибки). Таким образом, любые файлы, которые уже были скомпилированы успешно, не будут перекомпилированы. Если вы хотите перекомпилировать все, вы можете запустить make clean all, чтобы удалить любые скомпилированные объекты, а затем снова запустить make.

Установка

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

$ make install

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

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

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


9
2017-07-31 14:09



Тим, мне бы хотелось прочитать ваш учебник, но ссылка, которую вы опубликовали, не работает. - gareth_bowles


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

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

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

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

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

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

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

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


5
2017-07-27 09:11





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

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

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

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

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

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

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

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

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


3
2017-07-27 09:13





Чтобы ответить на ваш вопрос, на днях я нашел хороший способ увидеть, какие библиотеки вы установили, а также версии (это на 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

3
2017-07-27 09:12





Саймон,

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

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

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

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

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

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

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

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

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

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


3
2017-07-27 09:22





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

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


3
2017-07-27 16:04