Jak si zobrazit pomocí Chrome a na Chromiu založených webových prohlížečích stránky s neplatným certifikátem? Stačí napsat thisisunsafe.
V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.
Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.
Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Tiskni
Sdílej:
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).
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.
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"
sys-root
? To je nějaký magický název, který gcc očekává, nebo to je dané čistě nastavením v linker skriptu?
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.
$ 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