Portál AbcLinuxu, 30. dubna 2025 09:12
Tiskni
Sdílej:
Problém se specifickýma knihovnama pro radio bych asi řešil jejich distribucí s programem nebo statickým linkováním...tohle ovšem ve většině distribucí neprojde ...
…Udelat vzdy specificky balicek pro distribuci, do nej nacpat vsechno, co ten program pouziva a s cim si nemuzes byt na distribuci jisty. Pri instalaci balicku se pak rozbali ty zdrojaky, zkompilujou a nainstalujou. Pri odinstalaci balicku se odinstaluje i ten vas program. Neni to cisty, ale zrejme to bude jedina moznost.…A kdyz nektera z tech knihoven uz v systemu je? Otevrem si pivo a budem se sazet ktery symbol zkoliduje jako prvni? Jako gentooista vidim tyhle prasarny z prvni ruky a fakt to miluju.
/opt
nebo /usr/local
. Pokud to má běžet na různých distribucích a jejich verzích, a pokud se autor nechce zbláznit, moc jiných možností není. Sice je to "ošklivý" přístup "skoro jak na Windows", ale prostě to funguje. Má to i další výhody, jako třeba možnost mít na disku více verzí aplikace zároveň.
Aby se taková aplikace dostala do repozitářů, musela by se často výrazně upravit, a navíc pro každou distribuci jinak - podle dostupných verzí knihoven, které mívají i krásné vlastnosti v podobě absence zpětné kompatibility. Asi i proto zatím neuspěla zádná snaha o možnost tvořit "distribučně nezávislé" balíčky.
Distribuční balíčkovací systém je velmi vhodný pro rozšířené a open source věci, protože se někomu (správcům balíků v distribucích) vyplatí jim věnovat čas a trvalou péči a integrovat je do ekosystému sdílených knihoven. I tak je k vzteku, třeba když na Debianu nemůžu normálně nainstalovat zároveň PHP 5.2 a 5.3, protože balíčky jsou tak udělané. Vlastní kompilace zdržuje, a často stejně vede ke shánění vhodných verzí -dev balíků, protože s těmi distribučními se to nesestaví. Pak Windows přístup nevypadá tak zle, když tam můžu mít vedle sebe třeba 20 verzí PHP (vím, že to přináší jiné problémy).
Co se týče knihovny mysqlclient, tak co vidíte jako chybu, tak to je vlastnost. Jedná se o verzování knihoven a to není záležitost vaší aplikace, ale balíčku, do kterého knihovna patří. Přečtěte si něco o verzování dymanických knihoven. Vaším úkolem je pouze před samotnou kompilací otestovat, že v systému je knihovna v požadované minimální verzi. O zbytek se postará linker.
Co se týče chybějících balíčků, tak řešení je úplně stejné jako s vaším programem. Prostě se musí do distribuce přidat jako samostatné balíky.
Ano, občas je to spousta práce a hodně to bolí. Ale z výsledku pak budou mít užitek i ostatní.
Doporučuji si najít uživatele vaší aplikace a zároveň dané distribuce a toho přesvědčit, ať vám program program zabalí a balík vnutí do distribuce.
Na oplátku buďte připraven na všetečné dotazy vývojářů distribuce a mějte připraveny opravdu dobré argumenty, proč vaše aplikace se sestavuje zrovna tak, nebo se smiřte, že budete muset jejich (často oprávněné) výtky reflektovat ve svém kódu.
Zatím je program distribuován jako komplet adresář, který se rozbalí do domácího adresáře a spustí.Hm, tam bude chyba. Ono to není jak ve windows, kde binárku se všemi fajly rozbalíš někam do systému a basta...
/usr/bin
, knihovny do /usr/lib
, aplikační data do /usr/share/jmeno-aplikace
, atd.Nástroje pro řízení překladu a instalace (cmake, autotools) právě za vás řeší rozhození do jednotlivých adresářů. Asi se budete divit, ale jsou distribuce, které knihovny strkají jinam než do /usr/lib. A právě proto distributor čeká, že tyto cesty budou konfigurovatelné.
pak budu postupně zkoumat jak co udělat aby to chodilo v Mandrivě, openSUSE, Fedořenemyslím si, že by to byl dobrý přístup, protože to dost možná povede k tomu, že budeš všechno předělávat na několikrát, spíš si zkus požadavky z jednotlivých distribucí dát dohromady a porovnat (myslímže budou velmi podobné), pak z toho třeba vykoumáš systémové řešení namísto hromady hacků přiohýbajících to pro jednu či druhou distribuci co se týče Fedory, zaměření programu jde sice mimo můj zájem, ale i tak bych přiložil ruku k dílu - mailni mi, jestli chceš abych se to pokusil zabalit a dostat do distribuce
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.