Řešení 1:
Omlouvám se, že na všechno přímo odpovídám, ale neznám žádné užitečné návody, často kladené otázky atd. V podstatě následuje 8 let tvorby desktopových aplikací (které pomáhám distribuovat), frustrace a googlování:
1. Jak zjistím, jaké argumenty předat ./configure?
Opravdu cvičte. Autotools je dostatečně snadné, protože je konzistentní. Ale existuje spousta věcí pomocí cmake nebo vlastních skriptů pro sestavení. Obecně platí, že ke konfiguraci byste neměli nic předávat, mělo by se zjistit, zda váš systém umí sestavit foo-tool nebo ne.
Konfigurační a GNU nástroje všechny hledají v /, /usr a /usr/local závislosti. Pokud instalujete cokoliv kamkoli jinam (což je nepříjemné, pokud byla závislost nainstalována MacPorts nebo Finkem), budete muset předat příznak pro konfiguraci nebo úpravu prostředí shellu, abyste pomohli nástrojům GNU najít tyto závislosti.
2. Jak fungují sdílené knihovny pod OS X / Linux – kde na souborovém systému žijí, jak je ./configure &&make najde, co se vlastně stane, když jsou propojeny
V Linuxu je třeba je nainstalovat do cesty, kterou dynamický linker najde, což je definováno v LD_LIBRARY_PATH proměnná prostředí a obsah /etc/ld.conf. Na počítačích Mac je to stejné pro většinu softwaru s otevřeným zdrojovým kódem téměř vždy (pokud se nejedná o projekt Xcode). Kromě toho, že proměnná env je DYLD_LIBRARY_PATH místo toho.
Existuje výchozí cesta, kterou linker hledá knihovny. Je to /lib:/usr/lib:/usr/local/lib
Můžete to doplnit použitím proměnné CPATH, nebo CFLAGS nebo libovolného množství dalších proměnných prostředí skutečně (pohodlně komplikované). Navrhuji CFLAGS takto:
exportovat CFLAGS="$CFLAGS -L/nová/cesta"
Parametr -L se přidá k cestě odkazu.
Moderní věci používají nástroj pkg-config. Moderní věci, které nainstalujete, také nainstalují soubor .pc, který popisuje knihovnu a kde se nachází a jak se na ni odkazovat. To může usnadnit život. Nedodává se však s OS X 10.5, takže jej budete muset nainstalovat také. Také mnoho základních deps to nepodporuje.
Aktem propojení je pouze „vyřešit tuto funkci za běhu“, ve skutečnosti je to velká tabulka řetězců.
3. Jaké jsou skutečné rozdíly mezi sdílenou a staticky propojenou knihovnou? Proč nemohu vše staticky propojit (RAM a místo na disku jsou v dnešní době levné) a vyhnout se tak podivným konfliktům verzí knihoven?
Když vytvoříte odkaz na soubor statické knihovny, kód se stane součástí vaší aplikace. Bylo by to, jako kdyby pro tuto knihovnu existoval jeden obří soubor .c a vy jste jej zkompilovali do své aplikace.
Dynamické knihovny mají stejný kód, ale při spuštění aplikace se kód načte do aplikace za běhu (zjednodušené vysvětlení).
Můžete staticky propojit se vším, ale bohužel to neusnadňují žádné sestavovací systémy. Budete muset upravit systémové soubory sestavení ručně (např. Makefile.am nebo CMakeLists.txt). To však pravděpodobně stojí za to se naučit, pokud pravidelně instalujete věci, které vyžadují různé verze knihoven a je pro vás obtížné paralelně instalovat závislosti.
Trik je změnit řádek odkazu z -lfoo na -l/path/to/static/foo.a
Pravděpodobně se dá najít a vyměnit. Poté pomocí ldd foo nebo otool -L foo zkontrolujte, zda nástroj neodkazuje na .so nebo dylib
Dalším problémem je, že ne všechny knihovny se kompilují do statických knihoven. Mnozí ano. Pak se ale MacPorts nebo Debian možná rozhodly, že to nebudou dodávat.
4. Jak zjistím, jaké knihovny mám nainstalované a jaké verze?
Pokud máte soubory pkg-config pro tyto knihovny, je to snadné:
pkg-config --list-all
Jinak to často snadno nejde. dylib může mít soname (tj. foo.0.1.dylib, soname je 0,1), které je stejné jako verze knihovny. To však není vyžadováno. Soname je funkce binární vyčíslitelnosti, pokud změníte formát funkcí v knihovně, musíte narazit na hlavní část soname. Můžete tedy získat např. verze 14.0.5 soname pro knihovnu 2.0. I když to není běžné.
Jsem z toho frustrovaný a vyvinul jsem pro to řešení na Macu a budu o tom mluvit dále.
5. Jak mohu nainstalovat více než jednu verzi knihovny, aniž bych narušil můj normální systém?
Moje řešení je zde:http://github.com/mxcl/homebrew/
Líbí se mi instalace ze zdroje a chtěl jsem nástroj, který by to usnadnil, ale s určitou správou balíčků. Takže s Homebrew stavím např. wget sám ze zdroje, ale ujistěte se, že instalujete na speciální předponu:
/usr/local/Cellar/wget/1.1.4
Poté pomocí nástroje homebrew vše symbolicky propojím do /usr/local, takže stále mám /usr/local/bin/wget a /usr/local/lib/libwget.dylib
Pokud později potřebuji jinou verzi wget, mohu ji nainstalovat paralelně a pouze změnit verzi, která je propojena se stromem /usr/local.
6. Pokud instaluji věci ze zdroje na systém, který je jinak spravován pomocí balíčků, jaký je nejčistší způsob, jak to udělat?
Věřím, že homebrew způsob je nejčistší, takže jej použijte nebo udělejte ekvivalent. Nainstalujte do /usr/local/pkgs/name/version a symbolický odkaz nebo pevný odkaz na zbytek.
Použijte /usr/local. Každý nástroj pro vytváření, který existuje, tam hledá závislosti a záhlaví. Váš život bude moc jednodušší.
7. Za předpokladu, že se mi podaří zkompilovat něco nešikovného ze zdroje, jak to pak mohu zabalit, aby ostatní lidé nemuseli skákat přes stejné obruče? Zejména na OS X....
Pokud nemá žádné závislosti, můžete rozbalit adresář sestavení a dát jej někomu jinému, kdo pak může provést "make install". To však můžete spolehlivě provést pouze pro přesně stejné verze OS X. Na Linuxu to pravděpodobně bude fungovat pro podobný Linux (např. Ubuntu) se stejnou verzí jádra a libc minor.
Důvodem, proč není snadné distribuovat binární soubory na Unix, je binární kompatibilita. Lidé z GNU a všichni ostatní často mění svá binární rozhraní.
V zásadě nedistribuujte binární soubory. Věci se pravděpodobně zlomí velmi podivným způsobem.
Na Macu je nejlepší možností vytvořit balíček macports. Každý používá macporty. Na Linuxu existuje tolik různých sestavovacích systémů a kombinací, nemyslím si, že existuje lepší rada, než napsat příspěvek na blog o tom, jak se vám podařilo vybudovat nástroj x v podivné konfiguraci.
Pokud vytvoříte popis balíčku (pro macports nebo homebrew), pak si tento balíček může nainstalovat kdokoli a také to řeší problémy se závislostmi. To však často není snadné a také není snadné zahrnout váš recept macports do hlavního stromu macportů. Macporty také nepodporují exotické typy instalací, nabízejí jednu volbu pro všechny balíčky.
Jedním z mých budoucích cílů s Homebrew je umožnit kliknutí na odkaz na webové stránce (např. homebrew://blah a stáhne se ten Ruby skript, nainstaluje se deps pro tento balíček a pak se vytvoří aplikace. Ale ano, ještě není hotovo, ale není to příliš složité vzhledem k designu, který jsem zvolil.
8. Jaké jsou nástroje příkazového řádku, které musím ovládat, abych se v tom vyznal? Věci jako otool, pkg-config atd.
otool je opravdu užitečný až potom. Říká vám, na co se vestavěný binární soubor odkazuje. Když zjišťujete závislosti nástroje, který musíte sestavit, je to k ničemu. Totéž platí pro pkg-config, protože již budete mít nainstalovanou závislost, než ji budete moci používat.
Můj řetězec nástrojů je, číst soubory README a INSTALL a provést konfiguraci --help. Sledujte výstup sestavení a zkontrolujte, zda je v pořádku. Analyzujte všechny chyby sestavení. Možná se v budoucnu zeptejte na serverfault :)
Řešení 2:
Toto je rozsáhlé téma, takže začněme sdílenými knihovnami na Linuxu (ELF na Linuxu a Mach-O na OS X), Ulrich Drepper má dobrý úvod do psaní DSO (dynamické sdílené objekty), které pokrývají historii dostupných sdílených knihoven na Linuxu. zde včetně toho, proč jsou důležité
Ulrich také popisuje, proč je statické propojení považováno za škodlivé, jedním z klíčových bodů jsou aktualizace zabezpečení. Přetečení vyrovnávací paměti v běžné knihovně (např. zlib), která je rozsáhle staticky propojena, může způsobit obrovskou režii pro distribuce – k tomu došlo u zlib 1.1.3 (informace Red Hat)
ELF
Manuální stránka linkeru ld.so
man ld.so
vysvětluje základní cesty a soubory zahrnuté v dynamickém linkování za běhu. Na moderních linuxových systémech uvidíte další cesty přidané přes /etc/ld.so.conf.d/ přidané obvykle prostřednictvím globu v /etc/ld.so.conf.
Pokud chcete vidět, co je dynamicky dostupné prostřednictvím vaší konfigurace ld.so, můžete spustit
ldconfig -v -N -X
Přečtení návodu k DSO by vám mělo poskytnout dobrou základní úroveň znalostí, abyste mohli dále porozumět tomu, jak tyto principy platí pro Mach-O v OS X.
Mach-O
V OS X je binární formát Mach-O. Dokumentace místního systému pro linker je
man dyld
Dokumentace formátu Mach je k dispozici od společnosti Apple
Nástroje pro vytváření UNIX
Běžné configure , make , make install Tento proces je obecně poskytován GNU autotools, který má online knihu, která pokrývá některé z historie rozdělení konfigurace/sestavení a GNU toolchain. Autoconf používá testy k určení dostupnosti funkcí v cílovém systému sestavení, používá k tomu jazyk maker M4. Automake je v podstatě metoda šablonování pro Makefiles, šablona se obecně nazývá Makefile.am, která vytváří soubor Makefile.in, který výstup autoconf (skript konfigurace) převede na soubor Makefile.
Program GNU hello funguje jako dobrý příklad pro pochopení GNU toolchainu - a manuál obsahuje dokumentaci autotools.
Řešení 3:
Simone! Vím, jak se cítíš; S touto částí učení Linuxu jsem také bojoval. Na základě svých vlastních zkušeností jsem napsal tutoriál o některých položkách, kterým se věnujete (většinou jako reference pro mě!):http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html. Myslím, že oceníte moji poznámku o tom, jak jednoduché je sestavení/instalace aplikací Pythonu. :)
Doufám, že to pomůže! A šťastné sestavování.
Tim Jones
Vytvoření/instalace aplikace ze zdroje v Ubuntu Linux
Zatímco repozitáře Ubuntu jsou přeplněné skvělými aplikacemi, jednou nebo jindy musíte narazit na nástroj, který musíte mít, který není v repozitářích (nebo nemá balíček Debian) nebo potřebujete novější verze než v repozitářích. Co děláš? No, musíte sestavit aplikaci ze zdroje! Nebojte se, opravdu to není tak složité, jak to zní. Zde je několik tipů založených na mých zkušenostech z doby, kdy jsem byl amatérským amatérem! (Zatímco v tomto příkladu používám Ubuntu, obecné koncepty by měly být použitelné pro většinu distribucí Unix/Linux, jako je Fedora, a dokonce i platformu Cygwin ve Windows.)
Základní proces sestavování (kompilace) většiny aplikací ze zdroje se řídí touto sekvencí:konfigurovat --> zkompilovat --> nainstalovat. Typické příkazy Unixu/Linuxu pro provádění těchto věcí jsou:config --> make --> make install . V některých případech dokonce najdete webové stránky, které ukazují, že vše lze spojit do jediného příkazu:
$ config && make && make install
Tento příkaz samozřejmě předpokládá, že v žádném z těchto kroků nejsou žádné problémy. Tady přichází zábava!
Začínáme
Pokud jste ještě nezkompilovali aplikaci ze zdrojového kódu ve vašem systému, budete ji pravděpodobně muset nastavit pomocí obecných vývojových nástrojů, jako je gcc sada kompilátorů, některé běžné hlavičkové soubory (představte si to jako kód, který již napsal někdo jiný, který používá program, který instalujete) a nástroj make. Naštěstí v Ubuntu existuje metabalík s názvem build-essential který nainstaluje toto. Chcete-li jej nainstalovat (nebo se jen ujistit, že jej již máte!), spusťte tento příkaz v terminálu:
$ sudo apt-get install build-essential
Nyní, když máte základní nastavení, stáhněte si zdrojové soubory aplikace a uložte je do adresáře, pro který máte oprávnění ke čtení/zápisu, jako je váš „domovský“ adresář. Obvykle budou v archivním souboru s příponou .tar.gz nebo .tar.bz2 . .tar jednoduše znamená, že je to "páskový archiv", což je seskupení souborů, které zachovává jejich relativní adresářovou strukturu. .gz znamená gzip (GNU zip), což je populární kompresní formát Unix/Linux. Podobně .bz2 znamená bzip2, což je novější kompresní formát, který poskytuje vyšší kompresi (menší velikost komprimovaného souboru) než gzip.
Po stažení zdrojového souboru otevřete okno terminálu (System Terminal z nabídky Ubuntu) a přejděte do adresáře, do kterého jste soubor uložili. (použiji ~/download v tomto příkladu. Zde je '~' zástupcem vašeho "domovského" adresáře.) Pomocí příkazu tar extrahujte soubory ze staženého archivního souboru:
Pokud je váš soubor archivem gzip (např. končí na .tar.gz ), použijte příkaz:
$ tar -zxvf filename.tar.gz
Pokud je váš soubor archiv bzip2 (např. končí na .tar.bz2 ), použijte příkaz:
$ tar -jxvf filename.tar.gz
Tip:Pokud si nechcete pamatovat všechny přepínače příkazového řádku pro extrahování archivů, doporučuji pořídit si jeden (nebo oba) z těchto nástrojů:dtrx (můj oblíbený!) nebo deco (populárnější). U kteréhokoli z těchto nástrojů stačí zadat název nástroje (dtrx nebo deco) a název souboru, o vše ostatní se postará on sám. Oba tyto „vědí“, jak zacházet s většinou jakéhokoli formátu archivu, se kterým se pravděpodobně setkáte, a mají skvělé zpracování chyb.
Při sestavování ze zdroje existují dva běžné typy chyb, se kterými se pravděpodobně setkáte:
- K chybám konfigurace dochází, když spustíte konfigurační skript (obvykle pojmenovaný config nebo configure) za účelem vytvoření souboru makefile, který je specifický pro vaše nastavení.
- K chybám kompilátoru dochází, když spustíte příkaz make (po vygenerování souboru makefile) a kompilátor nemůže najít nějaký kód, který potřebuje.
Podíváme se na každý z nich a prodiskutujeme, jak je vyřešit.
Chyby konfigurace a konfigurace
Po extrahování archivního souboru zdrojového kódu v terminálu byste měli přejít do adresáře, který obsahuje extrahované soubory. Obvykle bude tento název adresáře stejný jako název souboru (bez .tar.gz nebo .tar.bz2 rozšíření). Někdy je však název adresáře pouze názvem aplikace bez jakýchkoli informací o verzi.
Ve zdrojovém adresáři vyhledejte README soubor a/nebo INSTALL soubor (nebo něco s podobnými názvy). Tyto soubory obvykle obsahují užitečné informace o tom, jak sestavit/kompilovat aplikaci a jak ji nainstalovat, včetně informací o závislostech. "Závislosti" jsou jen ozdobný název pro další komponenty nebo knihovny, které jsou nutné k úspěšné kompilaci.
Poté, co si přečtete README a/nebo INSTALL (a doufejme, že jste se podívali na jakoukoli relevantní online dokumentaci k aplikaci), vyhledejte spustitelný soubor (má pro soubor nastaveno oprávnění "x") soubor s názvem config nebo configure . Někdy může mít soubor příponu, například .sh (např. config.sh ). Obvykle se jedná o skript shellu, který spouští některé další nástroje pro potvrzení, že máte „zdravé“ prostředí pro kompilaci. Jinými slovy, zkontroluje, zda máte nainstalované vše, co potřebujete.
Tip:Pokud se jedná o aplikaci založenou na Pythonu, místo konfiguračního souboru byste měli najít soubor s názvem
setup.pyAplikace .Python se obvykle instalují velmi jednoduše. Chcete-li nainstalovat tuto aplikaci jako root (např. dát sudoin před následující příkaz v Ubuntu), spusťte tento příkaz:$ python setup.py installTo by mělo být vše, co musíte udělat. Zbytek tohoto výukového programu můžete přeskočit a přejít přímo k používání a užívání aplikace.
Spusťte konfigurační skript v terminálu. Obvykle můžete (a měli byste!) spustit konfigurační skript pomocí svého běžného uživatelského účtu.
$ ./config
Skript zobrazí několik zpráv, abyste měli představu o tom, co dělá. Skript vám často poskytne informaci o tom, zda byl úspěšný nebo selhal, a pokud selže, některé informace o příčině selhání. Pokud se vám nezobrazují žádné chybové zprávy, můžete obvykle předpokládat, že vše proběhlo v pořádku.
Pokud nenajdete žádný skript, který by vypadal jako konfigurační, pak to obvykle znamená, že aplikace je velmi jednoduchá a je nezávislá na platformě. To znamená, že můžete jednoduše přeskočit na krok sestavení/kompilace níže, protože poskytnutý Makefile by měl fungovat na jakémkoli systému.
Příklad
V tomto tutoriálu použiji textovou RSS čtečku s názvem Newsbeuter jako příklad typů chyb, se kterými se můžete setkat při vytváření vaší aplikace. Pro Newsbeuter je název konfiguračního skriptu config.sh . V mém systému, když spustím config.sh , dojde k následujícím chybám:
[email protected]:~/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.
Po nějakém výzkumu jsem zjistil, že ve skutečnosti jde o sqlite3 aplikace byla nainstalována. Nicméně, protože se snažím stavět ze zdroje, toto je tip, že co config.sh ve skutečnosti hledá vývojové knihovny (hlavičky) pro sqlite3 . V Ubuntu má většina balíčků přidružený protějšek pro vývoj, který končí na -dev . (Jiné platformy, jako je Fedora, často používají příponu balíčku -devel pro vývojové balíčky.)
Chcete-li najít vhodný balíček pro sqlite3 vývojový balíček, můžeme použít apt-cache nástroj v Ubuntu (a podobně i yum nástroj ve Fedoře):
[email protected]:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite
Tento příkaz vrací poměrně velký seznam výsledků, takže musíme udělat trochu detektivní práce, abychom určili, který balíček je vhodný. V tomto případě se ukáže, že vhodný balíček je libsqlite3-dev . Všimněte si, že někdy balíček, který hledáme, bude mít lib prefix, namísto pouze stejného názvu balíčku plus -dev . Je to proto, že někdy jen hledáme sdílenou knihovnu, kterou může používat mnoho různých aplikací. Chcete-li nainstalovat libsqlite3-dev , spusťte v terminálu typický příkaz apt-get install:
[email protected]:~/download/newsbeuter-1.3$ sudo apt-get install libsqlite3-dev
Nyní musíme spustit config.sh znovu, abychom se ujistili, že jsme tento problém se závislostí vyřešili a že již nemáme žádné další problémy se závislostí. (I když to zde neukážu, v případě Newsbeuter jsem musel nainstalovat také libcurl4-openssl-dev balíček také.) Také pokud nainstalujete vývojový balíček (jako libsqlite3-dev ) a související balíček aplikací (např. sqlite3 ) ještě není nainstalován, většina systémů automaticky nainstaluje přidružený aplikační balíček ve stejnou dobu.
Když konfigurace proběhne úspěšně, výsledkem bude vytvoření jednoho nebo více make souborů. Tyto soubory se obvykle jmenují Makefile (pamatujte, že v Unixu/Linuxu záleží na velikosti písmen v názvu souboru!). Pokud balíček sestavení obsahuje podadresáře, například src , atd., každý z těchto podadresářů bude obsahovat Makefile také.
Chyby při sestavování a kompilaci
Nyní jsme připraveni aplikaci skutečně zkompilovat. Tomu se často říká stavba a název je vypůjčen z reálného procesu budování něčeho. Různé "části" aplikace, které jsou obvykle více soubory zdrojového kódu, jsou spojeny dohromady a tvoří celkovou aplikaci. Nástroj make spravuje proces sestavení a volá další aplikace, jako je kompilátor a linker, aby skutečně provedly práci. Ve většině případů jednoduše spustíte make (se svým běžným uživatelským účtem) z adresáře, kde jste spustili konfiguraci. (V několika případech, jako je kompilace aplikací napsaných pomocí knihovny Qt, budete muset místo toho spustit jinou „obalovací“ aplikaci, jako je qmake. Znovu vždy zkontrolujte README a/nebo INSTALL dokumenty pro podrobnosti.)
Stejně jako u konfiguračního skriptu výše, když spustíte make (nebo podobný nástroj) v terminálu, zobrazí se některé zprávy o tom, co se provádí, a všechna varování a chyby. Varování můžete obvykle ignorovat, protože jsou určena hlavně vývojářům aplikace a říkají jim, že jsou porušovány některé standardní postupy. Tato varování obvykle neovlivňují funkci aplikace. Na druhou stranu je třeba se vypořádat s chybami kompilátoru. S Newsbeuterem, když jsem spustil make, šlo chvíli vše dobře, ale pak se mi zobrazila chyba:
[email protected]:~/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
Proces vytváření se zastaví, jakmile dojde k první chybě. Zpracování chyb kompilátoru může být někdy ošemetná záležitost. Musíte se podívat na chyby, abyste našli nějaké vodítko k problému. Obvykle je problém v některých hlavičkových souborech, které mají obvykle příponu .h nebo .hpp , chybí. V případě výše uvedené chyby je (nebo by mělo být!) jasné, že problém je v tom, že stfl.h hlavičkový soubor nelze nalézt. Jak ukazuje tento příklad, chcete se podívat na první řádky chybové zprávy a postupovat dolů, abyste našli základní příčinu problému.
Poté, co jsem se podíval na dokumentaci Newsbeuter (což jsem měl udělat, než jsem začal, ale pak by tato část tutoriálu nebyla příliš smysluplná!), zjistil jsem, že vyžaduje knihovnu třetí strany s názvem STFL. Co tedy v tomto případě uděláme? No, v podstatě opakujeme přesně stejný proces pro požadovanou knihovnu:získejte knihovnu a spusťte pro ni proces configure-build-install a poté pokračujte ve vytváření požadované aplikace. Například v případě STFL jsem musel nainstalovat libncursesw5-dev balíček, aby se správně sestavil. (Obvykle není nutné opakovat konfigurační krok na naší původní aplikaci po instalaci další požadované aplikace, ale ani to nikdy neuškodí.)
Po úspěšné instalaci sady nástrojů STFL proběhl úspěšně proces vytváření pro Newsbeuter. Proces vytváření obvykle pokračuje tam, kde skončil (v bodě chyby). Žádné soubory, které již byly úspěšně zkompilovány, tedy nebudou znovu zkompilovány. Pokud chcete znovu zkompilovat vše, můžete spustit make clean all, abyste odstranili všechny zkompilované objekty, a poté znovu spustit make.
Instalace
Po úspěšném dokončení procesu sestavení jste připraveni nainstalovat aplikaci. Ve většině případů k instalaci aplikace do společných oblastí systému souborů (např. /usr/bin nebo /usr/share/bin , atd.), budete muset instalaci spustit jako root. Instalace je skutečně tím nejjednodušším krokem v celém procesu. Chcete-li nainstalovat, v terminálu spusťte:
$ make install
Zkontrolujte, zda na výstupu tohoto procesu nejsou nějaké chyby. Pokud bylo vše úspěšné, měli byste být schopni spustit název příkazu v terminálu a ten se spustí. (Pokud se jedná o aplikaci GUI, přidejte &na konec příkazového řádku, jinak nebudete moci používat terminálovou relaci, dokud aplikace neskončí.)
Když vytváříte aplikaci ze zdroje, obvykle nepřidá ikonu nebo zástupce do nabídek GUI v Ubuntu. Toto budete muset přidat ručně.
A to je v podstatě proces, i když potenciálně iterativní, k vytvoření a instalaci aplikace ze zdroje v Ubuntu. Jakmile to uděláte jen párkrát, stane se to pro vás druhou přirozeností!
Řešení 4:
./configure --help vám poskytne spoustu informací pro konfigurační soubory generované GNU autotools. Většina z toho se týká --with/--without pro aktivaci funkcí (tyto mohou vyžadovat další parametr, například "shared", který říká, kde najít knihovnu).
Dalšími důležitými jsou --prefix (ve výchozím nastavení je většinou /usr/local/), který říká, kam se má instalovat (pokud vytváříte balíčky, obvykle to chcete jako --prefix=/usr nebo možná --prefix =/opt/YourPackage).
Na Linuxu jsou /lib, /usr/lib a /usr/local/lib obecně prohledány v mém gcc a zahrnuty ve výchozí konfiguraci ldconfig. Pokud nemáte dobrý důvod, tady chcete mít své knihovny. /etc/ld.so.conf však může vypsat další položky.
nakonfigurujte a vyhledejte je pouhým pokusem spustit "gcc -l" a zjistit, zda došlo k chybě. Do parametru CFLAGS můžete přidat „-L“ a přidat další cesty k vyhledávání.
Můžete mít nainstalováno více verzí a software propojený se starší verzí zůstane s ní propojen (spusťte ldd, abyste zjistili vazbu na Linuxu), ale nové kompilace se obecně zaměřují na nejnovější verzi dynamické knihovny ve vašem systému.
Většina softwaru předpokládá dynamické knihovny, zvláště pokud používá libtool, takže se může stát, že se netriviální aplikace nestaví správně staticky.
ls -l je nejlepší způsob, jak najít nainstalované knihovny.
A to je místo, kde mi docházejí informace; jak si dobře hrát s balíčky:nevím. Když je to možné, snažím se věci zabalit do balíčku, abych se vyhnul problému.
Řešení 5:
Abych odpověděl na vaši otázku, našel jsem nedávno dobrý způsob, jak zjistit, jaké knihovny máte nainstalované a jaké verze (toto je na Linuxu Debian, takže by to mělo fungovat i s jinými verzemi).
dpkg --list
Měli byste získat opravdu dlouhý seznam s nějakým výstupem, jako je tento
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