Kompiliace programů v Rustu a C pro ARM (diskuse)

[Petr]

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

[kotrcka]

+3.14

[mirec]

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).

[Pavel Píša]

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.

[Pavel Píša]

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ě.

[kralyk z abclinuxu]

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

[Pavel Píša]

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"

[kralyk z abclinuxu]

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?

[Pavel Píša]

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.

[kralyk z abclinuxu]

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.

[nyan]

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...