abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 15:00 | Nová verze

    Byla vydána nová stabilní verze 6.11 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    dnes 01:44 | Bezpečnostní upozornění

    Ubuntu 26.04 patrně bude ve výchozím nastavení zobrazovat hvězdičky při zadávání hesla příkazu sudo, změna vychází z nové verze sudo-rs. Ta sice zlepší použitelnost systému pro nové uživatele, na které mohlo 'tiché sudo' působit dojmem, že systém 'zamrzl' a nijak nereaguje na stisky kláves, na druhou stranu se jedná o možnou bezpečnostní slabinu, neboť zobrazování hvězdiček v terminálu odhaluje délku hesla. Původní chování příkazu sudo

    … více »
    NUKE GAZA! 🎆 | Komentářů: 7
    včera 21:33 | Komunita

    Projekt systemd schválil kontroverzní pull request, který do JSON záznamů uživatelů přidává nové pole 'birthDate', datum narození, tedy údaj vyžadovaný zákony o ověřování věku v Kalifornii, Coloradu a Brazílii. Jiný pull request, který tuto změnu napravoval, byl správcem projektu Lennartem Poetteringem zamítnut s následujícím zdůvodněním:

    … více »
    NUKE GAZA! 🎆 | Komentářů: 13
    včera 17:22 | Nová verze

    Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 163 (pdf).

    Ladislav Hagara | Komentářů: 0
    21.3. 15:22 | IT novinky

    Eric Lengyel dobrovolně uvolnil jako volné dílo svůj patentovaný algoritmus Slug. Algoritmus vykresluje text a vektorovou grafiku na GPU přímo z dat Bézierových křivek, aniž by využíval texturové mapy obsahující jakékoli předem vypočítané nebo uložené obrázky a počítá přesné pokrytí pro ostré a škálovatelné zobrazení písma, referenční ukázka implementace v HLSL shaderech je na GitHubu. Slug je volným dílem od 17. března letošního

    … více »
    NUKE GAZA! 🎆 | Komentářů: 3
    21.3. 15:11 | Zajímavý projekt

    Sashiko (GitHub) je open source automatizovaný systém pro revizi kódu linuxového jádra. Monitoruje veřejné mailing listy a hodnotí navrhované změny pomocí umělé inteligence. Výpočetní zdroje a LLM tokeny poskytuje Google.

    Ladislav Hagara | Komentářů: 13
    21.3. 04:44 | Zajímavý software

    Cambalache, tj. RAD (rapid application development) nástroj pro GTK 4 a GTK 3, dospěl po pěti letech vývoje do verze 1.0. Instalovat jej lze i z Flathubu.

    Ladislav Hagara | Komentářů: 0
    20.3. 14:55 | Nová verze

    KiCad (Wikipedie), sada svobodných softwarových nástrojů pro počítačový návrh elektronických zařízení (EDA), byl vydán v nové major verzi 10.0.0 (𝕏). Přehled novinek v příspěvku na blogu.

    Ladislav Hagara | Komentářů: 0
    20.3. 13:22 | IT novinky

    Letošní Turingovou cenu (2025 ACM A.M. Turing Award, Nobelova cena informatiky) získali Charles H. Bennett a Gilles Brassard za základní přínosy do oboru kvantové informatiky, které převrátily pojetí bezpečné neprolomitelné komunikace a výpočetní techniky. Jejich protokol BB84 z roku 1984 umožnil fyzikálně zaručený bezpečný přenos šifrovacích klíčů, zatímco jejich práce o kvantové teleportaci položila teoretické základy pro budoucí kvantový internet. Jejich práce spojila fyziku s informatikou a ovlivnila celou generaci vědců.

    Ladislav Hagara | Komentářů: 18
    20.3. 04:44 | Zajímavý článek

    Firefox 149 dostupný od 24. března přinese bezplatnou vestavěnou VPN s 50 GB přenesených dat měsíčně (s CZ a SK se zatím nepočítá) a zobrazení dvou webových stránek vedle sebe v jednom panelu (split view). Firefox Labs 149 umožní přidat poznámky k panelům (tab notes, videoukázka).

    Ladislav Hagara | Komentářů: 2
    Které desktopové prostředí na Linuxu používáte?
     (15%)
     (7%)
     (1%)
     (12%)
     (29%)
     (2%)
     (5%)
     (1%)
     (13%)
     (24%)
    Celkem 1137 hlasů
     Komentářů: 27, poslední 17.3. 19:26
    Rozcestník

    Rukověť baliče RPM - XI (Architektury, systémy, platformy)

    27. 7. 2005 | David Nečas | Návody | 5718×

    Na které architektuře lze balíček kompilovat, na kterých platformách lze potom spustit.

    Architektury, systémy, platformy

    Ne všechny programy bohužel pracují na všech operačních systémech a architekturách. A některé jsou natolik speciální, že to od nich ani nikdo nečeká. Spec soubor proto může deklarovat, pro které architektury, případně i pro které operační systémy, lze balíček zkompilovat.

    Kompilační architektura

    Architekturu, na níž lze balíček zkompilovat, deklaruje položka BuildArch hlavičky (kdo rád píše dlouhé názvy, může použít i synonymum BuildArchitectures)

    BuildArch: i386 i586 i686 ppc64 alphaev67
    

    Při kompilaci se pak rpmbuild pokusí najít shodu mezi hodnotami v BuildArch a architekturou, na níž kompilujeme. Nepodaří-li se mu najít vůbec žádnou kompatibilní, kompilace selže.

    První nalezená přípustná hodnota v BuildArch pak určuje koncovku rpm, tj. ono i386lobster-1.10-1.i386.rpm. Jenže pro jaký procesor se balíček opravdu kompiluje, to určuje volba --target. To moc nedává smysl, že? Položka BuildArch se tak v praxi používá k jedinému účelu:

    BuildArch: noarch

    označuje balíčky obsahující jen data či skripty nezávislé na platformě. Ty pak dostanou koncovku noarch.

    Výhradní a zakázané architektury

    Procesory a systémy, pro něž je možno balíček zkompilovat, deklarujeme následujícími položkami hlavičky:

    ExclusiveArch
    Výhradní architektura. Balíček můžeme kompilovat jen pro uvedené architektury.
    ExclusiveOS
    Výhradní operační systém. Balíček můžeme kompilovat jen pro uvedené operační systémy.
    ExcludeArch
    Zakázaná architektura. Balíček nelze kompilovat pro uvedené architektury.
    ExcludeOS
    Zakázaný operační systém. Balíček nelze kompilovat pro uvedené operační systémy.

    Deklaruje-li spec soubor

    ExclusiveArch: i686 pentium4 athlon x86_64
    

    a naše implicitní architektura je i386, balíček nezkompilujeme – musíme použít --target i686. Tím se drasticky odstraňuje neshoda mezi deklarovanou architekturou a realitou.

    Na Intelu se nám často bude hodit standardní makro %{ix86}, které expanduje na seznam všech možných IA32 procesorů.

    Volba --target a makro %configure

    Volba --target určuje cílovou platformu. To také znamená koncovku balíčku – neobsahuje-li tedy spec soubor položku BuildArch, která má vyšší prioritu. Zejména však definuje hodnoty maker %_target, %_target_cpu%_target_os; dále hodnotu makra %optflags a proměnné RPM_OPT_FLAGS obsahujících volby kompilátoru vhodné pro daný procesor (odkud se berou, to uvidíme níže), a tím i chování standardního makra %configure, jež tyto proměnné využívá a nastavuje podle nich CFLAGS, CXXFLAGSFFLAGS, které už opravdu ovlivňují vlastní kompilaci.

    Balíme-li program, který nemá configure, nebo nepoužíváme makro %configure, a chceme, aby na jeho kompilaci měl --target vliv, musíme do CFLAGS (případně dalších proměnných) přiřadit či přidat hodnotu RPM_OPT_FLAGS sami

    export CFLAGS="$RPM_OPT_FLAGS"

    Argument volby --target je obecně tzv. kanonický triplet procesor-vendor-operační_systém, např. i686-pc-linux-gnu. Nebo i nekanonický; v označení platforem je pěkný guláš a rpmbuild si dokáže přebrat ledasco. Zejména mu můžeme napsat jen procesor, a zbytek si doplní podle operačního systému, na němž běží. Toho jsme ostatně už využili výše.

    Navzdory všem složitostem tak nakonec --target obyčejně používáme jednoduše. Chceme-li zkompilovat balíček pro svou distribuci, který pojede jen na procesoru i686 (a vyšších) a bude pro něj optimalizován, spustíme:

    rpmbuild -bb --target i686 lobster.spec

    Podmínky

    Povolování a zakazování platforem položkami ExclusiveArch je dosti hrubé. Programy často lze zprovoznit na různých architekturách a operačních systémech, ovšem za cenu úprav a nastavení – pro každou platformu samozřejmě jiných. Spec soubory proto lze větvit podle architektury a/nebo operačního systému. Máme k disposici podmínky:

    %ifarch, %ifnarch
    Větvení podle architektury (positivní a negativní), využijeme hojně.
    %ifos, %ifnos
    Větvení podle operačního systému (positivní a negativní), využijeme málokdy.

    Syntaxe podmínek velmi připomíná preprocesor C, vypadá totiž:

    %iftyp_testu seznam_hodnot%else%endif

    přičemž část s %else je nepovinná. Rovná-li se cílová architektura (resp. systém) kterékoli hodnotě ze seznamu, je podmínka splněna (v případě negativní podmínky se výsledek pak přirozeně ještě zneguje).

    Aplikovat patch číslo 3 jen na sparc64 a ppc64 tak můžeme:

    %ifarch sparc64 ppc64
    %patch3 -p1 -b .multilib-hack
    %endif

    Konfigurace platforem, soubor rpmrc

    Některé informace o platformách jsou zadrátovány přímo do rpm; další jsou jsou v souboru rpmrc. Obsahuje několik tabulek (či zobrazení) ve formě řádků:

    název_tabulky: platforma: hodnota

    Platforma je označení procesoru nebo operačního systému. Názvy tabulek jsou utvořeny ze dvou částí oddělených volitelným podtržítkem. První část je arch, os, buildarch nebo buildos. Druhá část je typ tabulky: canon – kanonické jméno, compat – co je s čím kompatibilní, nebo translate – převod na implicitní kompatibilní platformu. Ne všechny kombinace dávají smysl, jen některé se používají, a ještě méně jich budeme někdy chtít měnit. Několik relativně zajímavých příkladů:

    buildarch_translate

    Zobrazení z architektury, na níž kompilujeme, na architekturu, pro niž kompilujeme. Standardní nastavení pro všechny IA32 procesory je

    buildarchtranslate: cokoli: i386

    tj. ať kompilujeme na čemkoli, kompiluje se pro i386. Má-li se na i686 implicitně kompilovat pro i686, změníme definici na

    buildarchtranslate: i686: i686
    arch_compat

    Deklarace kompatibilních architektur. Řádek

    arch_compat: athlon: i686

    říká, že balíčky pro i686 jsou kompatibilní s athlonem. Kompatibilita je transitivní, tudíž například pro intelí procesory stačí deklarovat kompatibilitu s nejbližším nižším, a na konci pak

    arch_compat: i386: noarch

    zajišťuje, že noarch balíčky lze instalovat na kterýkoli (intelí) procesor.

    arch_canon

    Převod na kanonický název (sub)architektury, hodnota je kanonický název a číslo architektury. Nejspíš nikdy nebudeme potřebovat měnit. Příklad:

    arch_canon: sun4c: sparc 3

    To ale není vše, co v rpmrc můžeme najít (nebo změnit). Kromě tabulek se v něm nastavuje několik proměnných. Řádky nastavující proměnné mají tvar:

    proměnná: hodnota

    přičemž proměnné existují tyto:

    optflags

    Asi nejzajímavější proměnná, definuje vhodné volby kompilátoru pro daný procesor. Právě tato hodnota se při kompilaci objeví v %optflagsRPM_OPT_FLAGS. První slovo v hodnotě je procesor, pro nějž volby překladače nastavujeme. Implicitní nastavení optflags pro ppc64 tak kupříkladu vypadá:

    optflags: ppc64 -O2 -g -fsigned-char
    macrofiles

    Soubory, z nichž mají rpmrpmbuild načíst při spuštění makra (v uvedeném pořadí), oddělené dvojtečkami, jak je v Unixu zvykem. Standardní hodnota je docela dlouhá a najdete si ji v rpmrc, za zmínku však stojí, že začíná

    /usr/lib/rpm/macros:/usr/lib/rpm/%{_target}/macros:…

    Po implicitním souboru s makry se tedy načte např. /usr/lib/rpm/i686-redhat-linux, existuje-li a kompilujeme-li na i686 RedHatu, a může změnit definice maker pro tuto konkrétní cílovou platformu.

    include

    Nic nedefinuje, ale vloží soubor, který je jeho hodnotou.

    provides

    Netuším, co dělá, ani jsem ji nikdy neviděl.

    Soubor rpmrc tedy určuje, kde se hledají soubory s makry, ale kde se hledá rpmrc sám? Buď v adresářích, které dáme jako argument rpm --rcfile, nebo v implicitním seznamu adresářů, který je zakompilován do rpm a typicky vypadá:

    /usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc

    Nejvíce nás zajímá ~/.rpmrc, který si můžeme vytvořit v domovském adresáři a má nejvyšší prioritu. Do souboru /etc/rpmrc bychom případně psali společnou konfiguraci. Do /usr/lib/rpm/rpmrc nepíšeme nic, protože obsahuje implicitní hodnoty a nejbližší aktualizace RPM by nám jej přepsala.

    Nejčtenější články posledního měsíce

    Týden na ScienceMag.cz: Umělá inteligence kopíruje vědce, má své výsledky umět zdůvodňovat
    Týden na ScienceMag.cz: Rychlost rozpínání vesmíru by se mohla měřit i z gravitačních vln
    Jaderné noviny – přehled za leden 2026

    Nejkomentovanější články posledního měsíce

      všechny statistiky »

    Seriál Rukověť baliče RPM (dílů: 15)

    Rukověť baliče RPM - I (Úvod) (první díl)
    <—« Rukověť baliče RPM - X (Skriptíky)
    »—> Rukověť baliče RPM - XII (Makra, úvod)
    Rukověť baliče RPM 15 - XV (Závěr) (poslední díl)

    Související články

    Rukověť baliče RPM - I (Úvod)
    Rukověť baliče RPM - II (Prostředí)
    Rukověť baliče RPM - III (Struktura spec souboru)
    Rukověť baliče RPM - IV (Fáze balení)
    Rukověť baliče RPM - V (Zdrojové soubory)
    Rukověť baliče RPM - VI (Makro %setup)
    Rukověť baliče RPM - VII (Podepisování, verze)
    Rukověť baliče RPM - VIII (Závislosti)
    Rukověť baliče RPM - IX (Sekce %files)
    Rukověť baliče RPM - X (Skriptíky)
    Rukověť baliče RPM - XII (Makra, úvod)
    Rukověť baliče RPM - XIII (Makra, dokončení)
    Rukověť baliče RPM - XIV (Přizpůsobení)
    Rukověť baliče RPM 15 - XV (Závěr)
    Na co se často ptáme: Balíčkovací systémy kromě posledního odstavce o checkinstallu.
    Nebojíme se kompilace - I (Teorie)
    Nebojíme se kompilace - II (GCC, configure, make, checkinstall) kompilace a instalace software, opět kromě části o checkinstallu.
    Balíčkovací systém Mandrake Linuxu RPM na uživatelské úrovni (a pro Mandrake).

    Odkazy a zdroje

    Doporučené čtení

    Další články z této rubriky

    VDR a DVB-T2, část 2.
    VDR a DVB-T2, část 1.
    Šifrovaný Proxmox VE 6: ZFS, LUKS, systemd_boot a Dropbear
    MapTiler – proměňte obrázek v zoomovatelnou mapu
    Syncthing
           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    28.7.2005 16:43 SAL
    Rozbalit Rozbalit vše noarch a i386 sucasne
    Ako sa da urobit aby jeden z generovanych balickov bol noarch a iny i386. Napr. mam skripty v pythone, ktore by mali byt noarch, ale ten isty tar obsahuje aj kniznice, ktore sa kompiluju a su zavisle na architekture. Ked pouzijem pre jeden package noarch a pre druhy i386, tak ten druhy RPM ignoruje.
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.