cross compiling

[The Hit-Man]

Ich bin mitlerweile recht fit, mit cross compiling ... Mein alter Thread hat mir echt viel dabei geholfen:
viewtopic.php?t=186246

Noch mal danke an JTH ... Nun habe ich doch noch mal Fragen...
Ich kann ja nun Pakete für eine andere Architektur bauen. Habe hier noch ein paar alte Raspberrys Pi 1 hier ( also armhf Architektur ). das OS was drauf ist, nennt sich retropie ( Debian Buster ).
https://retropie.org.uk/
1.
Wenn ich jetzt per cross compile von amd64 nach armhf ein Paket baue, bekomme ich auch das fertige .deb Paket und es läßt sich auf dem Rpi1 installieren. Allerdings wenn ich das Programm starten möchte, bekomme ich ein 'illegal instruction' oder ein 'segment fault'. Baue ich das Paket allerdings in einer chroot Umgebung von diesem retropie ( Debian Buster ), gibt es keine Probleme ... Programm läuft. Dauert natürlich alles ziemlich lange das Paket zu bauen und ist ja auch kein richtiges cross compiling. Muß ich beim croos compile noch irgendeine Option dazu Paken? armhf scheint != armhf zu sein?

2. Da ich mir schon so einige backports gebastelt hatte würde mich interessieren, was trage ich von einem backports Paket in die change.log ein? Oder lass ich die einfach so wie sie ist?

[MSfree]

Meines Wissens ist der RPi-1 armel und nicht armhf. Mit Executables auf armhf-Basis wirst du auf einem RPi-1 also nicht glücklich.

[The Hit-Man]

Meines Wissens ist der RPi-1 armel und nicht armhf. Mit Executables auf armhf-Basis wirst du auf einem RPi-1 also nicht glücklich.

Ahhhhhhhhh ... da haste wohl recht ...

[The Hit-Man]

So, habe dann echt mal 'armel' genommen und ich bekomme auch ein Paket mit 'armel' heraus ... aber läßt sich dann aber nicht installieren:

Code: Alles auswählen

root@retropie:/opt# dpkg -i /home/pi/htop_3.3.0-4_armel.deb 
dpkg: Fehler beim Bearbeiten des Archivs /home/pi/htop_3.3.0-4_armel.deb (--install):
 Paket-Architektur (armel) passt nicht zum System (armhf)
Fehler traten auf beim Bearbeiten von:
 /home/pi/htop_3.3.0-4_armel.deb
root@retropie:/opt# 

Das muß doch noch etwas anderes sein ...

[The Hit-Man]

Fehlt nicht irgendwie so etwas wie:

Code: Alles auswählen

-mcpu=arm1176jzf-s -mfpu=vfp

[niemand]

armel und armhf beziehen sich nur auf die FPU. Für Pi 1 wäre ARMv6 und armhf richtig, armel würde auch gehen, aber eben die FPU nicht nutzen. Debians armhf war allerdings für ARMv7 gebaut, und das passte nicht zum Pi 1.

Das war damals™ der Grund, dass alle Pakete aus Raspbians Repos kamen: die haben tatsächlich alles passend neu kompiliert. Heute kommt wohl ein Großteil der Pakete wieder direkt aus Debians Repos.

Bei deinem konkreten Problem: gucken, wofür der Rest des Systems kompiliert worden ist, und das entsprechend als Vorlage nutzen.

[The Hit-Man]

Verstehe ... Aber heute gibts doch richtige Debian Images oder irre ich mich da?
https://raspi.debian.net/tested-images/

Kann man sbuild nicht einfach die Argumente mit geben?

Code: Alles auswählen

-mcpu=arm1176jzf-s -mfpu=vfp

Dann müßte doch das richtige raus kommen?

[niemand]

Weiß ich nicht im Detail, ohne selbst erstmal schauen zu müssen – und da’s nicht mein Problem ist … ;)

Allerdings muss das Kompilat auch nicht nur zur CPU, sondern auch zum System passen, und da haben die Angaben keinen Einfluss drauf. Wenn ich vor der Frage stünde, würde ich mir die Binaries auf dem System angucken (file und so) und schauen, worin sie sich von den von mir gebauten unterscheiden. Dann würde ich schauen, was die Ursache für diesen Unterschied ist, und sie abstellen.

[The Hit-Man]

Wenn ich vor der Frage stünde, würde ich mir die Binaries auf dem System angucken (file und so) und schauen, worin sie sich von den von mir gebauten unterscheiden. Dann würde ich schauen, was die Ursache für diesen Unterschied ist, und sie abstellen.

Habe ich noch gar nicht dran gedacht ... Das teste ich mal ...

[The Hit-Man]

Hab mir einfach mal das Tool 'htop' vorgenommen. Einmal per cross compile:

Code: Alles auswählen

file htop.cross 
htop.cross: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=ffa98e771bb9667b0c6e627c7992242707112380, stripped

und ein mal in der chroot Umgebung:

Code: Alles auswählen

file htop
htop: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=ccbb0c49acd404961aaca59738da5ed63566c5e0, stripped

Jetzt sehe ich beim cross compile das Wörtchen pie, das ich beim Bauen in der chroot Umgebung komischer Weise nicht sehe. An sonsten scheint alles gleich zu sein?

[niemand]

Jetzt sehe ich beim cross compile das Wörtchen pie, das ich beim Bauen in der chroot Umgebung komischer Weise nicht sehe.

Das sollte hier nicht von großer Bedeutung sein.

Allerdings ist mir gerade aufgefallen, dass der letzte Fehler ja von deinem Paketmanagement ausgegangen ist, und nicht etwa beim Ausführversuch geworfen wurde. Entsprechend mag da beim Paketbau was schiefgelaufen/unpassend konfiguriert sein. Um zu schauen, ob auf Binary-Seite alles in Ordnung ist, könntest du dein htop mal manuell auf die Zielmaschine bringen und versuchen, es auszuführen.

[The Hit-Man]

Allerdings ist mir gerade aufgefallen, dass der letzte Fehler ja von deinem Paketmanagement ausgegangen ist, und nicht etwa beim Ausführversuch geworfen wurde. Entsprechend mag da beim Paketbau was schiefgelaufen/unpassend konfiguriert sein. Um zu schauen, ob auf Binary-Seite alles in Ordnung ist, könntest du dein htop mal manuell auf die Zielmaschine bringen und versuchen, es auszuführen.

Ich hatte ja explizit mal 'armel' genommen, nehme ich 'armhf', so wie es die Zielarchitektur auch ist ( Retropie / buster ), wird das Paket ohne Probleme installiert, bekomme aber einen 'Illegal Instruction' Fehler.
Ah, ich glaube, jetzt weiß ich was Du meinst. Ich starte einfach mal das gebaute 'armel' Binary auf dem Zielhost ohne den Paketmanager. Mal sehen was passiert.

[The Hit-Man]

Ahhhhhhhhh ... Du hattest recht ... Nehme ich das Binary einfach aus dem 'armel' .deb ohne es zu installieren dann läuft es auf dem Raspberry Pi 1. Das ist ja schon mal sehr gut zu wissen. Also ich die Architektur für den Rapberry Pi 1 dann doch armel.
Jetzt müßte mein Paket das 'htop_3.3.0-4_armel.deb' heißt, irgendwie installierbar werden. Bringt das was es umzubenennen in 'htop_3.3.0-4_armhf.deb' ? Das es vielleicht installierbar wird?

[niemand]

Bringt das was es umzubenennen in 'htop_3.3.0-4_armhf.deb' ? Das es vielleicht installierbar wird?

Vermutlich nicht, aber wenn du’s wirklich schmutzig magst, könntest du zusätzlich in der control (im Paket in Archiv control.tar.xz) den „Architecture“-Eintrag entsprechend ändern.

Sauberer wär’s, das Paket für die richtige Architektur, also ARMv6 und armhf, neu zu bauen.

[The Hit-Man]

Sauberer wär’s, das Paket für die richtige Architektur, also ARMv6 und armhf, neu zu bauen.

Klar aber wie? Ich baue ja so:

Code: Alles auswählen

sbuild -d buster --host=armhf --no-run-autopkgtest --no-run-lintian htop

Da kommt dann ein fertiges htop Paket raus mir der Bezeihnung 'armhf'. Die zwar installierbar wäre aber eben eine Fehlermeldung bringt, weil falsche Architektur.

Code: Alles auswählen

sbuild -d buster --host=armel --no-run-autopkgtest --no-run-lintian htop

Baue ich das Paket so, würde es wohl auf der Hostarchitektur laufen, läßt sich aber per Paketmanager nicht installieren ... Eben weil in der control Datei usw. die Architektur 'armel' steht. Hatte da ja rein geschaut ...

Was macht man denn da jetzt? Bin verwirrt

[niemand]

Da kommt dann ein fertiges htop Paket raus mir der Bezeihnung 'armhf'. Die zwar installierbar wäre aber eben eine Fehlermeldung bringt, weil falsche Architektur.

Dort mal geschaut, was file zu dem Binary sagt?

Ist ein bisschen ungeschickt weil verwirrend, dass die Debianleute „armhf“ und „armel“ als Architekturbezeichnungen genommen hatten – sind ja keine verschiedenen Architekturen, tatsächlich kann man die softfloat-Variante auch unter armhf starten, wie du ja selbst gesehen hast.

Wenn die Fehlermeldung beim Ausführen sinngemäß was von „falsche Architektur“ oder „falscher Befehlssatz“ oder so sagt, dann liegt’s eher daran, dass das Binary nicht für ARMv6 gebaut worden ist.

[The Hit-Man]

Das armel binary sagt:

Code: Alles auswählen

file htop 
htop: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=b9f0dbb50491b9edb1b7707869c09654c93072ef, stripped

Das armhf binary sagt:

Code: Alles auswählen

file htop 
htop: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=ffa98e771bb9667b0c6e627c7992242707112380, stripped

Bin aber trotzdem noch überfragt ...

[The Hit-Man]

Hab mich mal weiter gelesen. Man braucht wohl auch das passende toolchain dafür. Aber dann kann ich wohl sbuild oder pbuilder nicht mehr benutzen.
Gibt es nicht irgendwelche Build-Farmen, wie zum Beispiel:
https://build.opensuse.org/

Allerdings wird da wohl kein armv6l mehr unterstützt.
Auf einem alten Raspberry Pi 1 oder in einer chroot Umgebung etwas zu bauen, dauert ja ewig ...

[The Hit-Man]

Weiß jemand hier mit was anzufangen? Ist das nicht so etwas wie eine Build-Farm?
https://portal.cfarm.net/machines/list/

[niemand]

Steht eigentlich alles da: https://gcc.gnu.org/wiki/CompileFarm

Man braucht wohl auch das passende toolchain dafür. Aber dann kann ich wohl sbuild oder pbuilder nicht mehr benutzen.

Ähm … ja – ohne die lässt’s sich nicht bauen. Da du’s aber bereits gebaut hast, wie du oben schreibst, wirst du die wohl schon haben.

Wie ist denn nun der aktuelle Stand bei dir?

[The Hit-Man]

Bis jetzt mache ich es weiter in der chroot Umgebung. Ist ja im Endeffekt das gleiche wie qemu ... Hab ja nen Rechner mit 8 Kernen und die werden auch alle benutzt aber bei einer ARM Emulation, naja, naja ...

[niemand]

https://wiki.debian.org/CrossCompiling mal gelesen?

[The Hit-Man]

https://wiki.debian.org/CrossCompiling mal gelesen?

Ja klar ... Ich bekomme es ja auch hin per sbuild oder pbuilder, cross Pakete zu bauen. Aber auf meinem Raspberry ( retropie OS / buster ), läuft es ja nicht so wie ich will.

[niemand]

Deswegen fragte ich nach dem aktuellen Stand. Bringt ja nix, wenn ich hier Hinweise gebe, denen du schon lange gefolgt bist. Also: was hast du bislang gemacht, mit welchem Ergebnis?

[The Hit-Man]

Deswegen fragte ich nach dem aktuellen Stand. Bringt ja nix, wenn ich hier Hinweise gebe, denen du schon lange gefolgt bist. Also: was hast du bislang gemacht, mit welchem Ergebnis?

Aber genau das steht doch im Thread?