Навчання компілювати речі з джерела (на Unix / Linux / OSX)


47

У той час як я встановлюю програмне забезпечення з пакетів (MacPorts / apt-get) там, де це можливо, мені часто виникає необхідність збирати пакети з джерела. ./configure && make && sudo make installзазвичай достатньо, але іноді це не працює - і коли цього не відбувається, я часто застрягаю. Це майже якось стосується інших залежностей бібліотеки.

Я хотів би дізнатися наступне:

  • Як я можу з’ясувати, до яких аргументів перейти ./configure?
  • Як працюють спільні бібліотеки в ОС X / Linux - де вони перебувають у файловій системі, як ./configure && makeїх знаходять, що насправді відбувається, коли вони пов’язані з
  • Які фактичні відмінності між спільною та статично пов'язаною бібліотекою? Чому я не можу просто статично зв’язати все (оперативна пам’ять та дисковий простір дешеві в наші дні), і, отже, уникнути дивних конфліктів у версії бібліотеки?
  • Як я можу сказати, які бібліотеки я встановив і які версії?
  • Як я можу встановити більше однієї версії бібліотеки, не порушуючи нормальної системи?
  • Якщо я буду встановлювати речі з джерела в системі, в іншому випадку управляються з допомогою пакетів, що найчистіший спосіб зробити це?
  • Якщо припустити, що мені вдається скласти щось чудово з джерела, як я можу потім упакувати це, щоб інші люди не повинні стрибати через ті самі обручі? Особливо на OS X ....
  • Які інструменти командного рядка мені потрібно освоїти, щоб отримати гарний результат? Такі речі, як otool, pkg-config тощо.

Я готовий вкласти тут небагато часу та зусиль - я не обов'язково хочу прямих відповідей на вищезазначені питання, я б швидше отримав рекомендації щодо книг / навчальних посібників / FAQ, які я можу прочитати, які дадуть мені знання, які мені потрібні, щоб зрозуміти, що відбувається насправді, і, отже, самостійно вирішити проблеми.

Відповіді:


40

Прошу вибачення за те, що безпосередньо відповідав на все, але я не знаю жодних корисних підручників, поширених запитань тощо. В основному, наступним є 8 років виготовлення настільних додатків (які я допомагаю поширювати), розчарування та гуглінг:

1. Як зрозуміти, які аргументи передати ./configure?

Практикуйте по-справжньому. Автоінструменти досить прості, як і послідовні. Але є багато речей, що використовують cmake або спеціальні сценарії побудови. Як правило, вам не потрібно нічого пропускати для налаштування, він повинен з’ясувати, чи може ваша система створити foo-інструмент чи ні.

Налаштування та інструменти GNU усі шукають у /, / usr та / usr / local для залежностей. Якщо ви встановите що завгодно деінде (що робить речі болючими, якщо залежність була встановлена ​​MacPorts або Fink), вам доведеться передати прапор, щоб налаштувати або змінити середовище оболонки, щоб допомогти інструментам GNU знайти ці залежності.

2. Як спільні бібліотеки працюють в OS X / Linux - де вони перебувають у файловій системі, як ./configure && робить їх знахідками, що насправді відбувається, коли вони пов’язані з

В 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 / new / path"

Параметр -L додає до шляху посилання.

У сучасних матеріалах використовується інструмент pkg-config. Сучасний матеріал, який ви встановлюєте, також встановлює .pc файл, який описує бібліотеку, де вона знаходиться та як пов’язатись із нею. Це може полегшити життя. Але він не поставляється з OS X 10.5, тому вам доведеться встановити і його. Також багато базових програм не підтримують це.

Акт зв’язування - це просто "вирішити цю функцію під час виконання", це дійсно велика таблиця рядків.

3. Які фактичні відмінності між спільною та статично пов'язаною бібліотекою? Чому я не можу просто статично зв’язати все (оперативна пам’ять та дисковий простір дешеві в наші дні), і, отже, уникнути дивних конфліктів у версії бібліотеки?

При посиланні на статичний файл бібліотеки код стає частиною вашої програми. Було б так, якби для цієї бібліотеки був один гігантський .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

Інакше часто не можеш легко. Диліб може мати ім’я (наприклад, foo.0.1.dylib, ім'я 0.1), що є таким же, як і версія бібліотеки. Однак цього не потрібно. 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. Якщо я встановлюю речі з джерела в системі, якою в іншому випадку керуються за допомогою пакетів, який найчистіший спосіб зробити це?

Я вважаю, що спосіб доморощенія найчистіший, тому використовуйте його або робіть еквівалент. Встановіть до / usr / local / pkgs / name / version та символізуйте або жорстке посилання на решту.

Використовуйте / usr / local. Кожен інструмент побудови шукає там залежності та заголовки. Ваше життя буде набагато простішим.

7. Припускаючи, що мені вдається скласти щось чудово з джерела, як я можу потім упакувати це, щоб інші люди не повинні стрибати через ті самі обручі? Особливо на OS X ....

Якщо у нього немає залежностей, ви можете орієнтувати каталог збірки та надати його комусь іншому, який зможе зробити "встановити". Однак ви можете зробити це надійно лише для тих самих версій OS X. У Linux він, ймовірно, буде працювати для аналогічного Linux (наприклад, Ubuntu) з тією ж версією Kernel та другорядкою libc.

Причина розповсюдження бінарних файлів на Unix є не простою причиною через те, що бінарна сумісність. Люди GNU та всі інші часто змінюють свої бінарні інтерфейси.

В основному не розповсюджуйте двійкові файли. Напевно, речі будуть ламатися дуже дивними способами.

На Mac найкращим варіантом є виготовлення пакету макспортів. Усі користуються макпортами. В Linux є так багато різних систем побудови та комбінацій, я не думаю, що немає кращого поради, ніж написати запис у блозі про те, як вам вдалося побудувати інструмент x у дивної конфігурації.

Якщо ви робите опис пакета (для макпортів або домашнього перекладу), його може встановити будь-хто, і він також вирішує проблеми залежності. Однак це часто непросто, і також непросто включити рецепт макпортів до основного дерева макпортів. Також макпорти не підтримують екзотичні типи встановлення, вони пропонують один вибір для всіх пакетів.

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

8. Які інструменти командного рядка мені потрібно освоїти, щоб отримати хороший результат? Такі речі, як otool, pkg-config тощо.

отоол справді корисний лише згодом. Він говорить вам, до чого побудовані бінарні посилання. Коли ви з'ясовуєте залежність інструменту, який ви повинні побудувати, це марно. Те ж саме стосується і pkg-config, оскільки ви вже встановили залежність, перш ніж можете використовувати його.

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


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

12

Це величезна тема, тому давайте почнемо із спільних бібліотек на 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 в ОС X.

Мах-О

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

man dyld

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

Інструменти для збирання UNIX

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

Привіт GNU програма діє як хороший приклад для розуміння набору інструментів GNU - і керівництво включає в себе Autotools документації.


10

Симоне! Я знаю як ти почуваєшся; Я також боровся з цією частиною вивчення 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.

Завантаживши вихідний файл, відкрийте вікно терміналу (системний термінал у меню 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) для створення файлу makefile, який є специфічним для вашої установки.
  2. Помилки компілятора трапляються, коли ви запускаєте команду make (після створення файлу makefile), і компілятор не в змозі знайти потрібний код.

Ми розглянемо кожне з них і обговоримо, як їх вирішити.

Помилки конфігурації та конфігурації

Після того, як ви вилучили файл архіву вихідного коду, у терміналі слід перейти до каталогу, який містить витягнуті файли. Зазвичай ім'я цього каталогу буде таким самим, як ім'я файлу (без .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 install у терміналі:

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

Тепер нам потрібно запустити config.shще раз, щоб переконатися, що ми вирішили цю проблему залежності і що більше не виникне проблем із залежністю. (Поки я не показуватиму це тут, у випадку Newsbeuter, мені також довелося встановити libcurl4-openssl-devпакунок.) Також, якщо ви встановите пакет розробки (як libsqlite3-dev) і пов'язаний пакет додатків (наприклад, sqlite3), це не вже встановлена, більшість систем автоматично встановлюватиме відповідний пакет додатків одночасно.

Коли конфігурація працює успішно, результатом буде те, що вона створить один або кілька файлів створення. Ці файли, як правило, називають Makefile(пам’ятайте, що випадок імені файлу має значення в Unix / Linux!) Якщо пакет складання включає підкаталоги, такі як srcтощо, кожен із цих підкаталогів також буде містити a Makefile.

Помилки побудови та компіляції

Тепер ми готові фактично скласти заявку. Це часто називають будівництвом, а назва запозичена з реального процесу побудови чогось. Різні "шматочки" програми, які, як правило, є декількома файлами вихідного коду, об'єднуються разом для формування загальної програми. Утиліта make керує процесом збирання та закликає інші програми, такі як компілятор і лінкер, фактично виконати роботу. У більшості випадків ви просто запускаєте make (зі своїм звичайним обліковим записом користувача) з каталогу, де ви запустили конфігурацію. (У кількох випадках, наприклад, для компіляції програм, написаних з бібліотекою Qt, вам потрібно буде замість цього запустити інший додаток "обгортки", наприклад, qmake. Знову ж таки, завжди перевіряйте деталі READMEта / або INSTALLдокументи.)

Як і у сценарії конфігурації, описаному вище, коли ви запускаєте make (або подібну утиліту) в терміналі, він відображатиме деякі повідомлення про те, що виконується, та будь-які попередження та помилки. Зазвичай ви можете ігнорувати попередження, оскільки вони в основному стосуються розробників програми та говорять їм, що існують деякі стандартні практики, які порушуються. Зазвичай ці попередження не впливають на функцію програми. З іншого боку, потрібно усунути помилки компілятора. З Newsbeuter, коли я бігав робити, на деякий час все пішло нормально, але потім я отримав помилку:

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

Процес виготовлення припиниться, як тільки з’явиться перша помилка. Поводження з помилками компілятора часом може бути складним бізнесом. Ви повинні подивитися на помилки, щоб знайти деякі підказки про проблему. Зазвичай проблема полягає в тому, що деякі файли заголовків, які зазвичай мають розширення .hабо .hpp, відсутні. У випадку помилки, зазначеної вище, очевидно, що проблема полягає в тому, що stfl.hфайл заголовка неможливо знайти. Як показує цей приклад, ви хочете переглянути перші рядки повідомлення про помилку і пропрацювати свій шлях вниз, щоб знайти основну причину проблеми.

Переглянувши документацію Newsbeuter (яку я повинен був зробити ще до того, як почати, але тоді ця частина підручника не була б дуже значущою!), Я виявила, що для неї потрібна стороння бібліотека під назвою STFL. То що ми робимо в цьому випадку? Ну, ми, по суті, повторюємо цей самий той самий процес для потрібної бібліотеки: отримати бібліотеку та виконати для неї процес налаштування-збірки-встановлення, а потім відновити створення потрібного додатку. Наприклад, у випадку з STFL, мені довелося встановити libncursesw5-devпакет, щоб він міг правильно скластись . (Зазвичай не потрібно повторювати етап налаштування нашої оригінальної програми після встановлення іншого необхідного додатка, але це ніколи не шкодить.)

Після успішної установки інструментарію STFL процес виготовлення Newsbeuter пройшов успішно. Процес виготовлення зазвичай підбирається там, де він залишається (в момент помилки). Таким чином, усі файли, які вже успішно складені, не будуть перекомпільовані. Якщо ви хочете перекомпілювати все, ви можете запустити очистити все, щоб видалити всі складені об'єкти, а потім запустіть зробити знову.

Встановлення

Після успішного завершення процесу збирання ви готові встановити додаток. У більшості випадків, щоб встановити додаток у загальні області файлової системи (наприклад, /usr/binабо /usr/share/binтощо), вам потрібно буде запустити інсталяцію як root. Установка - це дійсно найпростіший крок у всьому процесі. Щоб встановити, у терміналі запустіть:

$ make install

Перевірте результат цього процесу на наявність помилок. Якщо все вдалося, вам слід мати змогу запустити ім'я команди в терміналі, і воно запуститься. (Додайте & до кінця командного рядка, якщо це програма GUI або ви не зможете використовувати термінальний сеанс, поки програма не закінчиться.)

Коли ви створюєте додаток з джерела, він зазвичай не додає піктограму чи ярлик до меню GUI в Ubuntu. Це потрібно буде додати вручну.

І в основному це процес, хоча і потенційно ітеративний, створення та встановлення програми з джерела в Ubuntu. Коли ви зробите це лише кілька разів, це стане для вас другою природою!


Тіме, я хотів би прочитати ваш підручник, але посилання, яке ви опублікували, не працює.
gareth_bowles

6

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

Інші важливі з них --prefix (який за замовчуванням / usr / local / більшу частину часу), щоб сказати, куди потрібно встановити (якщо ви будуєте пакети, ви зазвичай хочете це як --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 - ваша найкраща пропозиція знайти встановлені бібліотеки.

І ось тут мені не вистачає інформації; як добре грати з пакетами: не знаю. Коли це можливо, я намагаюся загортати речі в пакет, щоб уникнути проблеми.


4

"Як я можу з’ясувати, які аргументи передати ./configure?"

зазвичай: ./configure --help скаже вам, що ви хочете там.

"Як я можу сказати, які бібліотеки я встановив і які версії?"

Це залежить від системи. Один із способів - це просто зробити так, find /|grep libname|lessяк зазвичай бібліотечні файли мають версію у імені файлу.

"Як я можу встановити більше однієї версії бібліотеки, не порушуючи нормальної системи?"

Знову ж таки, залежить від системи та бібліотеки. sudo make altinstallстворить для вас ім’я, що переосмислюється. Файли бібліотеки, як правило, самі версії. Майте на увазі, однак; оскільки версії часто створюють посилання на "нормалізоване" ім'я, це може порушити ситуацію.

"Якщо я встановлюю речі з джерела в системі, якою в іншому випадку керується за допомогою пакетів, який найчистіший спосіб зробити це?"

Використання параметрів --prefix у ./configure та розміщення їх десь у /optнас є хорошою практикою.

Відмова: Я ні в якому разі не експерт, але я використовував Linux більше 5 років з cmd-лінії (slackware, CentOS, redhat, ubuntu, misc others та OS X).


4

Щоб відповісти на ваше запитання, я знайшов хороший спосіб, щоб побачити, які бібліотеки ви встановили та версії (це на 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

4

Саймон,

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 допоможе вам багато, але тільки для програмного забезпечення, яке його використовує. Це не є частиною за замовчуванням системи побудови автоінструментів, хоча вона популярна в наші дні.


4

Статичні бібліотеки не є хорошою ідеєю - якщо вам потрібно оновити бібліотеку (наприклад, щоб виправити проблему безпеки), вам потрібно буде перекомпілювати все, залежно від цієї бібліотеки.

Мені не подобається, що ідея "зробити встановлення" потенційно псується з моєю системою, але, як вже говорили інші, зазвичай набагато менше болів встановлювати речі в / usr / local замість того, щоб використовувати --prefix для іншої установки. Отже, я порушив / usr / local моєму постійному (непривілейованому) користувачеві. Таким чином, "зробити встановлення" майже гарантовано не возитися з важливими системними файлами. (Це, очевидно, не буде працювати у багатокористувацьких системах. Це чудово для віртуальних серверів.)


4

Хоча це явно не було у вашому списку питань, ви згадуєте у передмові:

./configure && make && sudo make install зазвичай достатньо, але іноді це не працює - і коли цього не відбувається, я часто застрягаю.

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

Побачити:

Ще один інструмент, який може бути вам корисним - CheckInstall, він додає додатки, встановлені разом make installіз вашим списком встановлених пакетів: https://help.ubuntu.com/community/CheckInstall


3

Для ОС X:

  • Як визначити, які аргументи передати ./configure?

./конфігурувати - допомогти

  • Які фактичні відмінності між спільною та статично пов'язаною бібліотекою? Чому я не можу просто статично зв’язати все (оперативна пам’ять та дисковий простір дешеві в наші дні), і, отже, уникнути дивних конфліктів у версії бібліотеки?

Використання спільних бібліотек дозволяє оновити бібліотеку без перекомпіляції всього, що використовує її.

  • Як працюють спільні бібліотеки під OS X / Linux - де вони перебувають у файловій системі, як ./configure && робить їх знахідками, що насправді відбувається, коли вони пов’язані з

Системні бібліотеки живуть у / 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, щоб створити пакет дебюту.

  • Якщо припустити, що мені вдається скласти щось чудово з джерела, як я можу потім упакувати це, щоб інші люди не повинні стрибати через ті самі обручі? Особливо на OS X ....

Я б сказав, задокументуйте етапи компіляції в публікації в блозі.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.