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 17:55 | Zajímavý projekt

CSIRT.CZ informuje o CTF (Capture the Flag) platformě ZSIS CTF s úlohami pro procvičování praktických dovedností z oblasti kybernetické bezpečnosti a upozorňuje na soutěž Google Capture the Flag 2018, kde je možné vyhrát zajímavé ceny.

Ladislav Hagara | Komentářů: 0
dnes 17:00 | Komunita

Byly zveřejněny prezentace a videozáznamy přednášek z prvního československého setkání síťových operátorů CSNOG konaného 11. a 12. června v Brně a semináře IPv6 2018 uskutečněného 6. června v Praze.

Ladislav Hagara | Komentářů: 0
dnes 16:11 | Komunita

Svobodný unixový operační systém FreeBSD slaví 25 let. Přesně před pětadvaceti lety, tj. 19. června 1993, byl vybrán název FreeBSD.

Ladislav Hagara | Komentářů: 0
dnes 15:11 | Komunita

Oficiální YouTube kanál Blenderu je již několik dní blokován. Nadace Blender Foundation informuje, že od společnosti Google dostala šestistránkový návrh nové smlouvy (pdf). Zdá se, že podmínkou další spolupráce je zapnutí reklam na kanálu, tj. zpeněžení obsahu.

Ladislav Hagara | Komentářů: 14
dnes 01:55 | Nová verze

Byla vydána verze 1.13 multiplatformního open source textového editoru Brackets (Wikipedie, GitHub). Přehled novinek v oficiálním oznámení a v poznámkách k vydání. Brackets je nově dostupný také jako balíček ve formátu Flatpak z oficiálního repozitáře Flathub.

Ladislav Hagara | Komentářů: 3
včera 18:44 | Komunita

Oficiální YouTube kanál Blenderu je již několik dní blokován. Důvody jsou zatím nejasné. Pravděpodobně chyba YouTube. Dění lze sledovat na Twitteru Tona Roosendaala.

Ladislav Hagara | Komentářů: 14
včera 17:55 | Zajímavý software

Na GitHubu byly pod open source licencí LLVM zveřejněny zdrojové kódy překladače programovacího jazyka C++ Zapcc vycházejícího z Clangu/LLVM. Překlad pomocí Zapccu je díky lepšímu kešování obvykle několikrát rychlejší než překlad pomocí Clangu. V březnu loňského roku byl vydán Zapcc ve verzi 1.0.

Ladislav Hagara | Komentářů: 0
včera 17:22 | Pozvánky

Červnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 21. 6. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: F-Droid, aneb svobodný software do vašeho mobilu. Kromě toho budou k vidění i vývojové desky HiFive1 se svobodným/otevřeným čipem RISC-V.

xkucf03 | Komentářů: 1
15.6. 22:44 | Zajímavý článek

Na blogu projektu NeoPG (GitHub), kryptografického softwaru vycházejícího z GnuPG, byly zveřejněny 4 příspěvky detailně popisující aktuální bezpečnostní problémy v GnuPG a souvisejících softwarových produktech. V prvním příspěvku je ukázáno, že je možné vytvořit zprávu, o které budou Earlybird, Evolution, Mutt nebo Outlook tvrdit, že jí dešifrovali a přitom ale zpráva vůbec zašifrována nebyla. V druhém příspěvku je popsána

… více »
Ladislav Hagara | Komentářů: 7
15.6. 13:00 | Komunita

GamingOnLinux informuje, že počítačová hra Track Mania Nations Forever (Steam, Wikipedie) pro Windows je nově dostupná také jako snap. Stejně jako v případě winepaku a Flatpaku se k běhu hry používá překladová vrstva Wine.

Ladislav Hagara | Komentářů: 12
Jak čtete delší texty z webových stránek?
 (78%)
 (22%)
 (4%)
 (7%)
 (2%)
 (11%)
Celkem 210 hlasů
 Komentářů: 36, poslední včera 21:16
    Rozcestník

    Kompiliace programů v Rustu a C pro ARM

    25.3.2016 11:47 | Přečteno: 1534× | Linux & programování | Výběrový blog | poslední úprava: 25.3.2016 16:35

    Pár tipů pro cross-kompilaci pro ARMové destičky. Zaměřeno na Arch Linux, ale myslím, že postupy jsou použitelné i jinde...

    GCC Toolchain

    Toolchain pro kopmilaci pro ARM je v Archu snadno dosptuný jako kolekce balíčků v AURu. Balíčky je potřeba sestavovat ve správném pořadí - nejdříve headers a binutils, pak gcc stage1 a stage2, pak glib a finální gcc. Je taky dobré si zdroják gcc nasdílet mezi balíčky pro různé stages, aby to člověk nestahoval 3×.

    Instalací těchto balíčků se nainstaluje sada binárek se jménem arm-linux-gnueabihf-* a prefix v /usr/arm-linux-gnueabihf, obsahující hlavičky a knihovny.

    Rust Toolchain

    Co se Rustu týče, nejsanžší & nejpohodlnější možnost je asi nástroj multirust.

    Pro instalaci hotové bínární distribuce Rust toolchainu použijeme příkaz:

    multirust add-target nightly armv7-unknown-linux-gnueabihf

    Případně obdobně pro toolchainy beta nebo stable. Příslušné knihovny se nainstanlují do ~/.multirust/toolchains/<toolchain>/lib/rustlib/armv7-unknown-linux-gnueabihf/

    Závislosti

    Typicky největším karambolem při cross-kompilaci jsou závislé knihovny a nástroje. Problém je, že způsob, jakým se kompilují, je každý pes jiná ves. Takže nejlepší je pokudmožno to vůbec neřešit a použít existující binárky - v případě Arch Linuxu je nejsnažší zamířit na stránky Arch Linux ARM a odtud si stáhnout hotový balíček s knihovnou. Z balíčku pak vybrakujeme soubory s hlavičkami a knihovnami a nainstalujeme je do prefixu /usr/arm-linux-gnueabihf.

    Napsal jsem si následující mírně zprasený skript armpkg, který tohle udělá za mě:

    #!/bin/sh
    
    
    if [[ ! -e "$1" ]]
    then
    	echo "Usage: armpkg ${0} <pkg file>"
    	exit 1
    fi
    set -e
    
    tdir="$(mktemp -d)"
    echo "Temp dir: $tdir"
    pkg="${tdir}/pkg"
    armpkg="${tdir}/armpkg"
    armprefix="${armpkg}/usr/arm-linux-gnueabihf"
    mkdir "$pkg" "$armpkg"
    bsdtar x -f "$1" -C "$pkg"
    cd "$tdir"
    
    echo "Creating prefixed package ..."
    [[ -e "${pkg}/.BUILDINFO" ]] && cp "${pkg}/.BUILDINFO" "$armpkg"
    sed -e '/^pkgname =/s/$/-arm/; s/^arch = .*$/arch = any/;' "${pkg}/.PKGINFO" > "${armpkg}/.PKGINFO"
    mkdir -p "$armprefix"
    [[ -d "${pkg}/usr/include" ]] && cp -r "${pkg}/usr/include" "${armprefix}/include"
    [[ -d "${pkg}/usr/lib" ]] && cp -r "${pkg}/usr/lib" "${armprefix}/lib"
    
    cd "$armpkg"
    pkgfiles='.PKGINFO *'
    [[ -e "${pkg}/.BUILDINFO" ]] && pkgfiles="$pkgfiles .BUILDINFO"
    # Generate .MTREE just like makepkg does:
    bsdtar c -zf .MTREE --format=mtree --options='!all,use-set,type,uid,gid,mode,time,size,md5,sha256,link' $pkgfiles
    bsdtar c -af "$tdir/pkg.tar.gz" .MTREE $pkgfiles
    
    set +e
    echo "Installing with 'sudo pacman' ..."
    sudo pacman -U "$tdir/pkg.tar.gz"
    
    rm -rf "$tdir"
    
    GCC toolchain pro ARM pak najde požadované hlavičky a knihovny tam, kde je očekává.

    Příklad: Kompilace nano

    Pro kompilaci nano budeme potřebovat zdrojový Archový balíček a jednu závislost: ncurses. ncurses stáhneme z repozitářů Arch Linux ARM a přebalíme výše zmíněným skriptem. Zdroj balíčku pro nano získáme v Archu pomocí abs.

    Při pohledu do PKGBUILDu nano je vidět, že jsou použity autotools. Autotools samy o sobě podporují cross-kompilaci, je ale vždy otázka, jestli s tím skripty daného projektu počítají. Takže zkusíme prostě v PKGBUILDu příkazu configure předhodit argument:

    --host=arm-linux-gnueabihf

    Což nás přivede k následující trochu kryptické chybě:

    configure: error: C compiler cannot create executables
    See `config.log' for more details

    Takže provedeme grep error config.log , a po odfiltrování nerelevantních stížností zjistíme, že:

    arm-linux-gnueabihf-gcc: error: unrecognized argument in option '-march=x86-64'
    arm-linux-gnueabihf-gcc: error: unrecognized argument in option '-mtune=generic'
    

    ... což tam zřejmě konfiguráky cpou bez ohledu na nastavenou volbu host. Opravíme to tím, že před ./configure nastavíme export CFLAGS="-Wall" a s tím už by mělo být nano sestaveno bez problémů:

    $ file pkg/nano/usr/bin/nano
    pkg/nano/usr/bin/nano: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
    dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,
    BuildID[sha1]=d14b0408fe4508984a05fe31f52f2d13b9e0afbd, not stripped
    

    Kompilace projektů v Rustu

    Za předpokladu, že je použito cargo a nainstalovaný toolchain, je postup snadný, stačí při volání cargo přidat argument

    --target=armv7-unknown-linux-gnueabihf

    Problém může opět být se závislostmi, pokud jsou linkované s céčkovými knihovnami. Tady opět neexistuje univerzálně platná rada, může být potřeba upravit build.rs v takové knihovně. Ale někdy je řešení snadné, například pro kompilaci frameworku Iron mně stačilo pouze stáhnout OpenSSL pro ARM a přebalit výše zmíněným skriptem, pak se celý Iron i se závislostmi zkompiloval pro ARM bez problému.

           

    Hodnocení: 100 %

            špatnédobré        

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

    Komentáře

    Vložit další komentář

    25.3.2016 14:57 Petr
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM
    Sice to 100% nikdy nevyužiju, ale díky za první přínosný blogpost za dlouhou dobu, jen díky lidem jako jsi ty není z ábíčka úplná žumpa
    26.3.2016 17:43 kotrcka | skóre: 23 | blog: Onééé 2 | Praha
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM
    +3.14
    You son of a bit.. coin
    mirec avatar 25.3.2016 17:22 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM

    Nie každý ARM je rovnaký. Spomínané balíčky pre arch sú skompilované s hard float point podporou (takže na platformách so softfp nepôjde). Ďalej tu máme rzdiely medzi rôznymi inštrukciami ako NEON, VFP ...

    Ja som kvôli tomu prešiel na crosstool-ng, balíky si kompiluejm cez buildroot (dá sa tam nastaviť externý toolchain).

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    26.3.2016 23:13 Pavel Píša | skóre: 12
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM

    Pozor při rozbalování knihoven na to, že GCC musí pro účely kompilace nalézt jako první libc.so, která ve skutečnosti není sdíleným objektem .so ale linker scriptem

    /* GNU ld script
       Use the shared library, but some functions are only in
       the static library, so try that secondarily.  */
    OUTPUT_FORMAT(elf32-littlearm)
    GROUP ( /lib/arm-linux-gnueabihf/libc.so.6 /usr/lib/arm-linux-gnueabihf/libc_nonshared.a  AS_NEEDED ( /lib/arm-linux-gnuea
    bihf/ld-linux-armhf.so.3 ) )
    

    Obecně je pak pro standardní kompilaci GCC s prefixem /user lepší nedávat nic do /usr/arm-linux-gnueabihf/lib (tedy až na ldscripts, které je součástí křízových binutils). Veškeré kódy z cílového systému je lepší dávat přímo, bez modifikací cest do /usr/arm-linux-gnueabihf/sys-root. GCC si správně do vyhledávacích cest vše přidá. Cesta ke compile time libc.so ld-scriptu je pak

    /usr/arm-linux-gnueabihf/sys-root/usr/lib/arm-linux-gnueabihf/libc.so
    

    Binární C knihovna s linky jsou pak v

    /usr/arm-linux-gnueabihf/sys-root/lib/arm-linux-gnueabihf/{libc.so,libc.so.6,libc-2.xx.so}
    

    Žádné modifikace cest pak nejsou potřeba. Dokonce při správném nakonfigurování usr/bin/qemu-arm-static do misc executable formats a nakopírování do sys-root/usr/bin lze normálně i na x86 stroji provést chroot do instalace distribuce pro target a spravovat balíčky nástroji distribuce. Na Debianu prostě udělám

    debootstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg --arch=armhf --include=debian-keyring,mc,libc6-dev,libstdc++6,busybox,aptitude jessie /srv/nfs/debian-armhf/ ftp://ftp.cz.debian.org/debian/
    

    Pak mohu /usr/arm-linux-gnueabihf/sys-root otočit jako symlink do /srv/nfs/debian-armhf/ doinstalovat v chrootu co chci, kompilovat cross-em vyexportovat a rovnou cílovou desku přes TFTP (jádro) a NFS (root filesystém) rozjet bez nutnosti jakýchkoliv opiček a instalování na SD kartu nebo jinam do cílové desky. Pokud pak pro standalone běh potřebuji systém zkonfigurovat, tak si z běžícího systému přes NFS sformátuji lokální úložiště a systém překopíruji na targetu. Vše přes SSH. Alternativně, pokud není médium NAND nebo eMMC, tak mohu SD kartu nakopírovat na vývojovém počítači.

    26.3.2016 23:16 Pavel Píša | skóre: 12
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM
    Ještě upozornění, tu libc.so je potřeba většinou pro cross poeditovat tak, aby absolutní cesty vedly tam, kde statické .a a dynamické .so skutečně je. Nevím jestli jde cesty specifikovat rozumně relativně.

    Takže v tomto jediném souboru se target FS liší od toho, který umožní kompilaci pomocí GCC přímo na cílové platformě.
    29.3.2016 12:36 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM
    To asi není úplně pro mě. Na tý ARM destičce můžu mít úplně jiné distro, kde je všechno jinak. Jasně, nějakej cross-compile chroot, kde bych si nastavil celej systém, by asi byl šikovnější, ale nevím jestli mám tu možnost a jestli se mi s tím chce nastavovat ;-)
    29.3.2016 23:12 Pavel Píša | skóre: 12
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM

    Debootstrap a chroot byly jen třešničky na dortu. Hlavní je, že pro normálně zkompilovaný cross-kompilátor není potřeba šachovat s cestami. Stačí to, co je pro kompilaci v "target" filesystému potřeba dávat pod /usr/arm-linux-gnueabihf/sys-root i včetně zanoření knihoven do podadresářů podle architektury atd. Přeskupením do adresáře čistě pro devel knihovny, jak máte ve Vašem skriptu, může dojít ke kolizím a problémům, viz libc.so.

    [[ -d "${pkg}/usr/include" ]] && cp -r "${pkg}/usr/include" "${armprefix}/include"
    [[ -d "${pkg}/usr/lib" ]] && cp -r "${pkg}/usr/lib" "${armprefix}/lib"
    
    30.3.2016 09:34 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM
    Nevím přesně jaké kolize máte na mysli, kolize souborů při instalaci balíčku odhalí pacman.

    Ještě se zeptám - proč se adresář jmenuje zrovna sys-root? To je nějaký magický název, který gcc očekává, nebo to je dané čistě nastavením v linker skriptu?
    30.3.2016 21:16 Pavel Píša | skóre: 12
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM

    Cesta je zakompilovaná do GCC podle nastavení v configure

    --with-build-sysroot=sysroot use sysroot as the system root during the build
      --with-sysroot[=DIR]    search for usr/lib, usr/include, et al, within DIR
    

    stejně tak do binutils

    --with-sysroot=DIR Search for usr/lib et al within DIR
    

    a lze ji i při volání GCC a ld měnit přepínačem --sysroot=<directory> a zakompilovanou hodnotu zjistit -print-sysroot. Ale teď zpětně si nejsem jistý, jestli je při defaultní kompilaci křížového GCC hodnota nastavená, protože já jí mám uvedenou v configure GCC a Binutils explicitně. Ale myslím, že jsem nastavení vzal podle nějakého vzoru.

    --with-headers=/usr/arm-rpi-linux-gnueabihf/sys-include \
    --with-sysroot=/usr/arm-rpi-linux-gnueabihf/sys-root \
    

    Při tvorbě kompilátoru, který mám do sebe zatáhnout podporu již existující binární GLIBC lze soubory rozkopírovat i do normálního taget include a lib. Ale může být konflikt, když je stejné jméno souboru v lib i v usr/lib. To může být případ libc.so. V každém případě, pokud jsem vytvářel kompilátor, který měl být čistý, to je neovlivněný již existující zkompilování GLIBC starým kompilátorem, tak sysroot byla nutnost. Protože se nejdříve musí vylákat build headers z jára, aniž máme kompilátor a pak správně podle těchto nakonfigurované hlavičky GLIBC, opět bez předchozí existence kompilátoru. Viz již poměrně staré mé poznámky

    https://rtime.felk.cvut.cz/hw/index.php/How_to_build_GNU_cross-compilers

    Vlastní jméno adresáře sys-root by mělo být defaultní podle https://gcc.gnu.org/install/configure.html a doporučené. Ale asi to chce zkontrolovat, zdá se, že se používají i jiná nastavení. V každém případě je podle GCC vývojářů/manuálu používat GCC pro nenativní kompilaci takto. Kopírování systémových hlaviček a knihoven není minimálně pro build doporučené. Ale dokud Vám to chodí a pokud se správně knihovny hledají i v architekturou prefixovaných podadresářích lib, tak to třeba ve Vašem případě není nutné. Za sebe si myslím, že úpravy cest nejsou správné, bezpečně vím o pár situacích kdy by mohly vést k chybám a zároveň ti kdo připravují křížová prostředí profesionálně (Qt, Pengutronix a další.) jednoznačně používají tato doporučená řešení. Ale tímto jsem se již po původním záměru nasměrovat na rozumné řešení a následné diskuzi vysílil a končím.

    30.3.2016 21:51 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM
    No s těmi balíčky z AURu je to asi trochu jinak, protože tam je sysroot nataven přímo na:

    $ arm-linux-gnueabihf-gcc -print-sysroot
    /usr/arm-linux-gnueabihf
    

    s tím, že usr/lib a usr/include jsou symlinky na lib a include o úroveň výš.
    Kopírování systémových hlaviček a knihoven není minimálně pro build doporučené.
    Možná došlo k nedorozumění, to gcc je zcela nové se vším všade od linux kernel headers přesně jak popisujete. Vykopírované knihovny jsou zkopírované z balíčků pro ARM pro stejnou architekturu, zkompilované stejným způsobem, takže to by taky mělo být ok.
    Ale tímto jsem se již po původním záměru nasměrovat na rozumné řešení a následné diskuzi vysílil a končím.
    V pořádku ;-) Já děkuji za rady.
    29.3.2016 19:25 nyan
    Rozbalit Rozbalit vše Re: Kompiliace programů v Rustu a C pro ARM
    Ja mam doma dve ARM desticky (jedna koupena, jedna darovana) a ARM musim zesumarizovat jako : hracky.

    Problem neni ve vykonu, problem je pristup vyrobcu. Reknou: Tady mate skvelou desticku. Tady k ni mate distro + kernel ktery sme udelali doma na kolene. Budeme se snazit dostat nase patche do upstream kernelu...

    A pak se tri mesice snazi, Linus nebo jeste nekdo pred nim je samozrejme posle do <> protoze jejich kod jsou desive sr**ky, a pak to vzdaji protoze musi delat na jejich dalsi uzasne desticce.

    Co zustane uzivateli ? Ma na vyber nestabilni made in china kernel deravy jak sito, nebo upstream kernel ktery nepodporuje 1/2 jeho hardwaru. A jakoze na nepodporu GPU jsme zvykly z PC, ale kernel ktery neumi pristupovat na NAND flash te desticky, je tak trochu k nicemu...

    Ted se objevil hardware ktery by byl konecne pouzitelny i pro development (ma to DDR3 SO-DIMM sloty), akorat nejak nemam chut davat $300 kdyz to bude zase to same...

    Jedina vyjimka v tomhle je mozna RaspPi, ale tam zas network i disky na jednom USB radici... hruza.

    A to jsme na tom zatim jeste dobre, az prijde Internet of things, to bude teprv zaplava sr**ek...

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.