Cross kompilácia NGINX

30.6.2014 14:30 | Přečteno: 3235× | Linux | poslední úprava: 30.6.2014 14:12

NGINX je síce vynikajúci webserver, ale jeho autori akosi nemysleli na možnosť cross kompilácie. V dnešnom blogu sa teda pozrieme na to ako ho skompilovať aj napriek tomu ;)

Na rozdiel od väčšiny softvéru NGINX má vlastný build systém. Configure skript je tak veľmi malý a elegantný (žiaden strojovo generovaný humus). Na druhej strane daňou za to je fakt, že nepodporuje také vymoženosti ako je cross kompilácia.

Funkcionalita configure skriptu je ukrytá v adresári auto. Zisťovanie prítomnosti "fičúr" danej platformy rieši súbor auto/feature. Samotný test spúšťa tento riadok:

if sh -c $NGX_AUTOTEST >> $NGX_AUTOCONF_ERR 2>&1; then

Testy sú väčšinou natívne binárky spúšťané cez shell. Vlastnosti ako veľkosť jednotlivých dátových typov sa zisťuje priamo v C operátorom sizeof. Aby sa tento test vykonal musíme ho teda spustiť na cieľovej platforme. Na začiatok teda prepíšeme niektoré výskyty sh -c za auto/run (kompletný zoznam je v priloženej záplate pre nginx 1.6.0) a vytvoríme súbor auto/run, ktorý je vybrakovaný z tohto tutoriálu.

#!/bin/bash
basedir=$(dirname $(readlink -f $0))
keyfile=${basedir}/remote-ssh-key
logfile=${basedir}/run.txt
verbose=

if [ -f "${basedir}/remote" ] ; then
  remote=$(<${basedir}/remote)
else
  echo -n "Vzdialeny stroj (username@192.168.1.1): "
  read remote
  echo "$remote" > ${basedir}/remote
fi

if [ "$1" = "-v" ] ; then
  verbose=1
  shift
fi

if [ -z "$1" ] ; then
  echo "Usage: $0 COMMAND ARG..."
  exit 1
fi

set -e -u

if [ ! -f $keyfile ] ; then
  echo "Generovanie kluca $keyfile" >> ${logfile}
  ssh-keygen -f ${keyfile} -N ""
  echo "Prenos kluca na vzdialeny system (zadajte prosim heslo)" >> ${logfile}
  scp -q ${keyfile}.pub ${remote}:/tmp
  echo "Pridanie kluca do authorized_keys (zadajte prosim heslo)" >> ${logfile}
  ssh -q ${remote} "mkdir -p ~/.ssh; chmod 700 ~ ~/.ssh; cat /tmp/remote-ssh-key.pub >> ~/.ssh/authorized_keys;"
fi

if [ -x "$1" ] ; then
  if [ -n "$verbose" ] ; then
     echo "Copying $1 to $remote" >&2
  else
     echo "$(date) Copying $1 to $remote" >> ${logfile}
  fi
  scp -q -i ${keyfile} "$1" ${remote}:/tmp
  remotename="/tmp/$(basename $1)"
  shift
  if [ -n "$verbose" ] ; then
     echo "Vzdialene spustenie: ${remotename} $@" >&2
  else
     echo "$(date) Vzdialene spustenie: ${remotename} $@" >> ${logfile}
  fi
  ssh -q -i ${keyfile} ${remote} "${remotename} $@"
else
  if [ -n "$verbose" ] ; then
     echo "Vzdialene spustenie: $@" >&2
  else
     echo "$(date) Vzdialene spustenie: $@" >> ${logfile}
  fi
  ssh -q -i ${keyfile} ${remote} "$@"
fi

Po spustení configure (pekne dlhá chvíľa čakania lebo po každom teste sa musí nadviazať spojenie) a make by sme mali mať funkčný nginx skompilovaný cross kompilátorom.

$buildhost = "/home/mirec/buildroot-armhf/output/host"
$sysroot = "$buildhost/usr/arm-buildroot-linux-gnueabihf/sysroot"


export PKG_CONFIG="$buildhost/usr/bin/pkg-config"
export PKG_CONFIG_LIBDIR="$sysroot/usr/lib/pkgconfig"
export PKG_CONFIG_SYSROOT_DIR="$sysroot"
export MAKEFLAGS=" -j3"
export cc=$buildhost/usr/bin/arm-cortex_a8-linux-gnueabi-gcc
export cpp=$buildhost/usr/bin/arm-cortex_a8-linux-gnueabi-cpp
export cflags="_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -pipe -Os "
export ldflags=""

./configure \
    --with-cc=$cc \
    --with-cpp=$cpp \
    --with-cc-opt=$cflags \
    --with-ld-opt=$ldflags \
    --crossbuild=arm-buildroot-linux-gnueabihf

       

Komentáře

[xkucf03]

pekne dlhá chvíľa čakania lebo po každom teste sa musí nadviazať spojenie

Tady by pomohlo ControlMaster – viz man ssh_config

[mirec]

Hmm, to je pekná vec, dobre vedieť, dik.

[BFU]

Misto toho se stacilo podivat, jak nginx korektne crosscompiluje Yocto/OE ... http://cgit.openembedded.org/meta-openembedded/tree/meta-webserver/recipes-httpd/nginx

[mirec]

Áno, presne tento patch s týmito parametrami som predtým používal (mimochodom je aj v mojom repozitári na githube, mal by som niekedy k nemu dať upozornenie, že nefunguje). Server síce nabehol, ale odoslal len prvých 16 bytov odpovede a zvyšok neinicializovaný. Niekde je tam proste oproti mojej platforme malý rozdiel, neskúmal som ho bližšie, vlastne bol som rád, že som po 6 hodínách špárania sa v openembedded dokázal pomocou iného návodu zostavi funkčný nginx.

[pavlix]

To je tak, když si někdo myslí, že za pár minut splácá lepší build systém než jsou ty existující a komplikuje tím maintainerům práci jak se dá.

[mirec]

Pravdu povediac stále si myslím, že je to o niekoľko tried lepšie než autotools. Ak sa niečo pokašle u ich build systému viem čo mám robiť. Ak sa niečo pokašle u autotools tak to môžem max tak prepísať do iného build systému (áno hovorím o stotinkových zmenách m4 a pod.).

[pavlix]

Pravdu povediac stále si myslím, že je to o niekoľko tried lepšie než autotools.

Na jednu stranu určitý odpor k autotools chápu, vzhledem k tomu, jaká je to bestie. Na druhou stranu jsem ještě nenarazil na jediný build systém pro software napsaný v céčku, který by se alespoň vzdáleně autotools vyrovnal a to bych byl moc rád, kdybych čistší náhradu do ruky dostal. Tím méně věřím tomu, že to bude platit pro cokoliv splácaného na koleni pro konkrétní software.

Mezi další výhody autotools patří to, že na všechno, co kdy potřebuju najdu někde na webu příklad toho, jak to řešili jiní. A pak historická návaznost a rozšířenost, díky kterým package maintainer zvládá pracovat s libovolným na autotools založeným balíkem, aniž by musel řešit, co všechno je jinak (jako to třeba řeším u softwaru, který se builduje pomocí cmake).

Ak sa niečo pokašle u autotools tak to môžem max tak prepísať do iného build systému

Moje zkušenost je taková, že ač autotools nejsou zrovna hezké nástroje, build na nich založený se poladit dá a především člověk užije zkušenosti z jiných toolů. To, že někdo staví software nad cmake, budiž, ale netriviální buildsystém pro každý jednotlivý balík je podle mého skromného názoru prasárna a přidělává to práci spoustě nevinných lidí. Ale plusem je, že to alespoň používá ./configure a make.

[mirec]

Ja to poznám skôr z pohľadu vývojára. A ako vývojár hovorím že hoc je cmake hnusný aký je (nemám ho rád, dúfam, že som to dostatočne jasne vyjadril ;)) myslím, že je 100x lepší než autotools.

Minule som napr. s autotools riešil pridanie stemmera pre slovenčinu do xapian-u. No človek by si povedal, že holt jednoduchá záležitosť tak som to teda pridal na tých asi 10 miest kde som mal a jeje ono to autogen je trochu sviňa a ak nemá presnú stotinkovú verziu autotools / m4 / milion ďalších závislostí tak sa to rozsype ako čaj. Áno, configure skript funguje, ale vygenerovať nový configure skript je utrpenie. Inak nakoniec som to poriešil tak, že som kompiloval ručne (áno príkaz po príkaze som si pekne písal, skompiloval som to, už na to nechcem šahnuť).

Ja som tých rôznych build systémov (aj na kolene robených) videl dosť. Okrem nginx som naposledy upravoval napr. configure skript QtAV ... Pridával som tam podporu hw dekódera cedar. Vyhľadanie knižníc a hlavičkových súborov (aj so štúdiom ako celý ten ich na kolene zbúchaný systém funguje) mi zabralo 5 minút.

[pavlix]

Ja to poznám skôr z pohľadu vývojára.

Já to znám jak z pohledu vývojáře, tak z pohledu uživatele.

A ako vývojár hovorím že hoc je cmake hnusný aký je (nemám ho rád, dúfam, že som to dostatočne jasne vyjadril ;)) myslím, že je 100x lepší než autotools.

Ani jako vývojář bych si nedovolil říct, že je jednoznačně lepší, natož stokrát, a chvílemi mám pocit, že je cmake nekompatibilní s dosavadní workflow úmyslně, jenom aby si autoři něco dokázali. A na vědomé neodůvodněně nekompatibilní změny jsem docela dost alergický. Při práci s balíky, co používají cmake, mám v jednom kuse pocit, že narážím na věci, které autotools zvládají bez problémů a cmake nikoliv.

vygenerovať nový configure skript je utrpenie

Vždyť se to dělá samo.

[mirec]

Vždyť se to dělá samo.

Kým nezačne vyhadzovať chyby syntaxe ktoré vznikli ktovie kde ;)

[pavlix]

No jak jsem řekl, až bude k dispozici něco, o čem budu most s klidným svědomím říci, že je to čistší plná náhrada autotools, tak se má smysl o tom bavit ;).

[R]

Dnes som potreboval skompilovat nieco pre Raspberry pi - nasiel som super nastroj qemu-debootstrap. Da sa s tym urobit v Debiane jednym prikazom chroot s inou architekturou. Funguje to potom ako obycajny chroot, akurat sa binarky automaticky spustaju cez qemu (s pomocou binfmt-support).

[mirec]

Hmm, tak riešiť to cez binfmt ma ani nenapadlo ;) Keď tak rozmýšľam v podstate stačilo mi nastaviť takto podobne interpreter (akurát teda by to bol skript ktorý by uploadoval binárky cez ssh), namountovať root cez sshfs a malo by o chodiť.

[R]

Mna by to tiez nenapadlo, ale zjavne niekoho v Debiane ano. Ani som nevedel, ze existuje "transparentne" qemu.