This commit is contained in:
parent
e73cfc3b9b
commit
54bd0c4947
@ -17,7 +17,7 @@ Es soll ja Menschen geben, die freiwillig jedes Stück Software, welches sie ein
|
|||||||
|
|
||||||
Manchmal gibt es aber Situationen, wo man einfach nicht drum rum kommt. In diesem Fall war das bei Node.js der Fall. Zum Hintergrund: Ich spiele seit einer Weile schon mit einer kleinen Sammlung SmartHome Devices herum. Dazu habe ich mir OpenHab als Zentrale auf einem Raspberry aufgesetzt und ein paar günstige aber duchaus brauchbare IKEA Tradfri Leuchtmittel zugelegt. IKEA setzt für diese Geräte auf Zigbee als Kommunikationsprotokoll, da das entsprechende Binding für OpenHab aber nicht so der Brüller ist, habe ich mich entschieden [zigbee2mqtt](https://github.com/Koenkk/zigbee2mqtt) als Vermittler dazwischenzuschalten. Das hat bis vor ein paar Wochen auch wunderbar funktioniert und dann kam ein Update. Viele neue Funktionen, auf die ich schon eine Weile gewartet habe und ehrlich gesagt auch etwas gespannt war. Mit dem Update kam aber auch ein Breaking Change: Der Node.js Support für Version 8 und 9 wird eingestellt, Mindestvoraussetzung ist jetzt die derzeitige LTS Version 10.x. Soweit ja okay immerhin gibt es mittlerweile für ARMv7 auch pre-compiled Binaries. Also fix die entsprechende Variable in Ansible angepasst, Playbook ausgeführt und siehe da: ERROR.
|
Manchmal gibt es aber Situationen, wo man einfach nicht drum rum kommt. In diesem Fall war das bei Node.js der Fall. Zum Hintergrund: Ich spiele seit einer Weile schon mit einer kleinen Sammlung SmartHome Devices herum. Dazu habe ich mir OpenHab als Zentrale auf einem Raspberry aufgesetzt und ein paar günstige aber duchaus brauchbare IKEA Tradfri Leuchtmittel zugelegt. IKEA setzt für diese Geräte auf Zigbee als Kommunikationsprotokoll, da das entsprechende Binding für OpenHab aber nicht so der Brüller ist, habe ich mich entschieden [zigbee2mqtt](https://github.com/Koenkk/zigbee2mqtt) als Vermittler dazwischenzuschalten. Das hat bis vor ein paar Wochen auch wunderbar funktioniert und dann kam ein Update. Viele neue Funktionen, auf die ich schon eine Weile gewartet habe und ehrlich gesagt auch etwas gespannt war. Mit dem Update kam aber auch ein Breaking Change: Der Node.js Support für Version 8 und 9 wird eingestellt, Mindestvoraussetzung ist jetzt die derzeitige LTS Version 10.x. Soweit ja okay immerhin gibt es mittlerweile für ARMv7 auch pre-compiled Binaries. Also fix die entsprechende Variable in Ansible angepasst, Playbook ausgeführt und siehe da: ERROR.
|
||||||
|
|
||||||
Toll, das NPM Modul von Ansible kann die Dependencys nicht installieren und quittiert das mit der Fehlermeldung `node: /lib/libstdc++.so.6: version GLIBCXX_3.4.20 not found (required by node)`. Na immerhin ein Ansatzpunkt. Problem an der Sache ist, dass Node die ARM Pakete per Cross Compiler unter Ubuntu 16 mit GCC4.9 baut und die entsprechende Bibliothek von libgcc dynamisch gelinkt ist, sprich nicht Teil der Binary ist, sondern vom Betriebssystem bereitgestellt und geladen wird. Für CentOS 7 ARMv7 gibt es aber keine neuere GCC Version und auch nicht die benötigte Library. Nach ein wenig Internetrecherchen und Gesprächen mit ein paar schlaueren Menschen war die potentielle Lösung allerdings schnell gefunden. Cross Compile auf einem System mit GCC4.9 und der Option `-static-libstdc++` sollte am Ende zu einer funktionierenden Binary führen. Klingt in der Theorie simpel, hat mich bei der konkreten Umsetzung dann doch ein paar Nerven gekostet.
|
Toll, das NPM Modul von Ansible kann die Dependencies nicht installieren und quittiert das mit der Fehlermeldung `node: /lib/libstdc++.so.6: version GLIBCXX_3.4.20 not found (required by node)`. Na immerhin ein Ansatzpunkt. Problem an der Sache ist, dass Node die ARM Pakete per Cross Compiler unter Ubuntu 16 mit GCC4.9 baut und die entsprechende Bibliothek von libgcc dynamisch gelinkt ist, sprich nicht Teil der Binary ist, sondern vom Betriebssystem bereitgestellt und geladen wird. Für CentOS 7 ARMv7 gibt es aber keine neuere GCC Version und auch nicht die benötigte Library. Nach ein wenig Internetrecherchen und Gesprächen mit ein paar schlaueren Menschen war die potentielle Lösung allerdings schnell gefunden. Cross Compile auf einem System mit GCC4.9 und der Option `-static-libstdc++` sollte am Ende zu einer funktionierenden Binary führen. Klingt in der Theorie simpel, hat mich bei der konkreten Umsetzung dann doch ein paar Nerven gekostet.
|
||||||
|
|
||||||
Meine Ansprüche an die Problemlösung:
|
Meine Ansprüche an die Problemlösung:
|
||||||
|
|
||||||
@ -25,7 +25,7 @@ Meine Ansprüche an die Problemlösung:
|
|||||||
- Cross Compiler Setup (macht auf dem Pi einfach kein Spaß und dauert ewig)
|
- Cross Compiler Setup (macht auf dem Pi einfach kein Spaß und dauert ewig)
|
||||||
- Automatisiertes Setup damit ich das auch für beliebiege andere Node.js Versionen machen kann
|
- Automatisiertes Setup damit ich das auch für beliebiege andere Node.js Versionen machen kann
|
||||||
|
|
||||||
Wer direkt Ergebnisse sehen will, anstatt sich den Quatsch hier durchzulesen, kann sich das Setup auf [GitHub](https://github.com/xoxys/nodejs-arm) anschauen. Für den Rest kommt jetzt noch eine kurze Erklärung des Setups. Die Kernkomponenten für die Umsetzung waren Drone CI, ein [Docker Image](https://cloud.docker.com/u/xoxys/repository/docker/xoxys/cc-arm) mit den benötigen Build Tools und der Cross Compiler Toolchain sowie ein Buildscript. Bauen lassen sich neue Versionen bequem über ein Release im Git Repo. Die Node Version wird dabei über den Releasetag gesteuert. Im Hintergrund passiert dabei durch die CI folgendes:
|
Wer direkt Ergebnisse sehen will, anstatt sich den Quatsch hier durchzulesen, kann sich das Setup auf [GitHub](https://github.com/xoxys/nodejs-arm) anschauen. Für den Rest kommt jetzt noch eine kurze Erklärung des Setups. Die Kernkomponenten für die Umsetzung waren [Drone CI](https://drone.io/), ein [Docker Image](https://cloud.docker.com/u/xoxys/repository/docker/xoxys/cc-arm) mit den benötigen Build Tools und der Cross Compiler Toolchain sowie ein Buildscript. Bauen lassen sich neue Versionen bequem über ein Release im Git Repo. Die Node Version wird dabei über den Releasetag gesteuert. Im Hintergrund passiert dabei durch die CI folgendes:
|
||||||
|
|
||||||
- Drone startet das Cross Compiler Image
|
- Drone startet das Cross Compiler Image
|
||||||
- Buildscript des Repositories wird aufgerufen
|
- Buildscript des Repositories wird aufgerufen
|
||||||
@ -33,10 +33,10 @@ Wer direkt Ergebnisse sehen will, anstatt sich den Quatsch hier durchzulesen, ka
|
|||||||
- Konfiguration für den Compiler erzeugen (Zielarchitektur, ARM spezifische Einstellungen, usw.)
|
- Konfiguration für den Compiler erzeugen (Zielarchitektur, ARM spezifische Einstellungen, usw.)
|
||||||
- make und make install (wichtig ist hier `PORTABLE=1` zu setzen)
|
- make und make install (wichtig ist hier `PORTABLE=1` zu setzen)
|
||||||
- tar.gz Archiv erzeugen
|
- tar.gz Archiv erzeugen
|
||||||
- RELEASENODE.md mit den Compileroptionen für diesen Build erzeugen
|
- RELEASENOTE.md mit den Compileroptionen für diesen Build erzeugen
|
||||||
- Drone erstellt Checksum
|
- Drone erstellt Checksum
|
||||||
- Signieren des Archivs per GPG
|
- Signieren des Archivs per GPG
|
||||||
- GitHub Release erzeugen, Dateien Anhängen und RELEASENODE.md schreiben
|
- GitHub Release erzeugen, Dateien Anhängen und RELEASENOTE.md schreiben
|
||||||
|
|
||||||
{{< imgproc release resize "950x" />}}
|
{{< imgproc release resize "950x" />}}
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user