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 18:44 | Bezpečnostní upozornění

Sabri Haddouche vytvořil stránku Browser Reaper, na které demonstruje zranitelnosti současných verzí webových prohlížečů Chrome, Safari i Firefox. Zveřejněné skripty dokážou zahltit nejen webové prohlížeče, ale v závislosti na nastavení, také celé operační systémy.

Ladislav Hagara | Komentářů: 6
včera 19:22 | Nová verze

Byla vydána verze 11.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
22.9. 13:00 | Komunita

Do 30. října se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 4. prosince 2018 do 4. března 2019, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 93
21.9. 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 8
21.9. 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
21.9. 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 11
21.9. 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
21.9. 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 6
20.9. 21:32 | Zajímavý projekt

Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.

Fluttershy, yay! | Komentářů: 2
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (24%)
 (4%)
 (0%)
Celkem 403 hlasů
 Komentářů: 34, poslední dnes 12:54
Rozcestník

Kompiliace programů v Rustu a C pro ARM

25.3.2016 11:47 | Přečteno: 1542× | 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.