[gelöst] Was ist Multiarch?

[bullgard]

Hallo Liste!
Ich verstehe in http://wiki.debian.org/Multiarch nicht den Satz

Multiarch is the term being used to refer to the capability of a system to install and run applications of multiple different binary targets on the same system. For example running a i386-linux-gnu application on an amd64-linux-gnu system.

Wahrscheinlich liegt das daran, daß ich nicht weiß, wie

binary targets

i386-linux-gnu application

und

amd64-linux-gnu system

definiert sind.
Wie sind bitte

binary targets

i386-linux-gnu application

und

amd64-linux-gnu system

definiert?

[Radfahrer]

Zitat aus den Release-Notes:

2.2.2. Multiarch

Neu in Debian 7.0 ist multiarch. Multiarch erlaubt es, Pakete mehrerer Architekturen auf derselben Maschine zu installieren. Dies ist in verschiedenen Fällen nützlich, aber der gängigste ist, sowohl 64-Bit- wie auch 32-Bit-Software auf dem gleichen Rechner zu installieren, wobei die Abhängigkeiten automatisch korrekt aufgelöst werden. Das Debian-Wiki enthält ein ausführliches Handbuch, wie Sie Nutzen aus dieser Funktionalität ziehen, falls Sie sie benötigen.

Sollte klar sein.

Das erwähnte Handbuch findet sich hier:
http://wiki.debian.org/Multiarch/HOWTO

[Dot]

Hallo bullgard,

hier mal ein ganz kurze, seeeehr oberfläche Erklärung.

binary targets

Sind die für die jeweilige Architektur übersetzten (compilierten) Programme. Nachdem ein Quellcode in Maschinesprache übersetzt wurde,
entsteht eine Binärdatei (die nur noch 0en und 1en enthält ) die dein Rechner lesen (ausführen) kann ... das ist das binary target, also z.B. die Programme auf deinem Rechner.

i386-linux-gnu application / amd64-linux-gnu system

X86/AMD64 sind Prozessorarchitekturen die sich unter anderem in ihrer "Wortlänge" also der Anzahl der bits die in einem Prozessortakt verarbeitet
werden können unterscheiden. AMD64 bzw. i386 sagt also für welche Architektur die Software (übersetzt) ist.

Multilib:
Um bisher auf einem 64bit Debian auch 32 Bit "Programme" ausführen zu können, mussten diverse Bibliotheken (librarys -> auch libs genannt ) nachinstalliert werden um dies zu ermöglichen (Bsp.: siehe Skype).

Ein Multilib System ermöglicht dir also beides also 32 bit sowie 64 bit "Programme" zu installieren und auszuführen.

Ich hoffe ich konnte ein wenig Licht ins Dunkel bringen.
dot

[NAB]

Gute Frage ...

Hier ist ein einfach gehaltener Artikel darüber:
http://www.pro-linux.de/news/1/17329/de ... tzung.html

Soweit ich das verstanden habe, geht es erst mal darum, die Struktur des Debian-Projektes zu verändern, angefangen bei der Organisation auf deren Servern, über den Aufbau von Installationsmedien, bis hin zu der Organisation der Programme auf deiner Festplatte.

Aktuell hast du davon noch keine Vorteile ... früher musstest du die "ia32-libs" installieren, um 32-Bit-Programme auf deinem 64-Bit-System laufen zu lassen, jetzt sorgt "multiarch" dafür.

Im Moment musst du dich noch entscheiden, ob du eine 32- oder 64-Bit Debian CD runterlädst, je nachdem, was du installieren willst. Irgendwann soll es mal eine universelle Installations-CD geben, die alle Architekturen abdeckt. Das wäre ohne die Umstrukturierung, die sich hinter "multiarch" versteckt, nicht möglich.

Ansonsten erleichtert die Sache wohl vorallem die Verwaltung und Entwicklung von Debian ... und schont ihre Server, wenn es nur noch ein Installationsmedium gibt, das man verteilen muss.

[bullgard]

Hallo Radfahrer, Dot, NAB!

Vielen Dank für Eure prima ausführlichen Antworten! Damit konnte ich gut etwas anfangen.

bullgard

[Meillo]

Grosses Lob! Dieses Thema ist fuer mich in jeder Hinsicht ein Vorzeigebeispiel.

[wanne]

@NAB: Nein, du wirst immer einen amd64 oder einen i386 Kernel haben dementsprechend ist es sinnvoll die umgebenden Programme darauf anzupasen. Dementsprechend sind auch auf immer 2 verschiedene Installer sinnvoll. (OK man kann beide auf die gleiche CD Brennen wie das Mageia macht aber im Prinzip sind das dann halt 2 Installer auf einer CD.) Der Sinn ist in erster linie dass man einfach ein Programm ener Beliebigen Architektur auswählen kann und dass dann über apt* installieren kann. Das System kümmert sich dann um den Rest der Nutzter muss nichts mehr selbst machen/wissen. Das ist gelungen.

@bullgard: Jeder Prozessor versteht eine Machienensprache. Prgramme die du ausführen Kannst müssen in dieser Sprache sein. (Für gewähnlich schreiben Menschen nicht in dieser sprache sondern in einer Hochsprache wie C und lassen das dann in die jeweilige Maschienensprache übersetzen. Das ist jetzt aber irrelevant.) Nun gibt es verschiedene Maschienensprachen. Dein Handy wird Programme die für deinen Computer sind nicht verstehen und umgekehrt. Vor etwa 10 Jahren entschied AMD (und kurz danach Intel) nun für PCs nichtmehr Prozessoren der Sprache x86 (bzw. i386 oder i686 (Das ist i386 mit ein paar neuen Wörtern)) sondern welche mit einer neuen sprache (amd64) herzustellen. (Vorteiele: Es gibt jetzt Wörter für das 5. GiB und Addiere 80000000000 und 90000000000 sowas musste man früher mühsam und ineffizient umschreiben.) Damit weiterhin alte Programme auf denen laufen können haben die einen Kompatiblitätsmodus. In anderen Sprachen gibt es ähnliche Fälle wo Prozessoren mehr als eine Sprache verstehen.
Debian bietet seit langem fast alle Programme in beiden Sprachen an. Problematisch sind Programme wie Skype die man nicht übersetzen darf. Um ein solches Programm im Kompatibilitätsmodus auszuführen braucht es auch alle Abhängigkeiten in der alten Sprache. Manche sachen brcaut es deswegen in 2 Sprachen. Multiarch sorgt dafür dass bei der Installation alle Abhängigkeiten in der Richtigen Sprache installiert werden und das 2 gleiche Abhängigkeiten in verschiedenen Sprachen sich nicht ins gehege kommen. Ohne das der Nutzer sich darum weiter kümmern muss.

[NAB]

@NAB: Nein, du wirst immer einen amd64 oder einen i386 Kernel haben dementsprechend ist es sinnvoll die umgebenden Programme darauf anzupasen. Dementsprechend sind auch auf immer 2 verschiedene Installer sinnvoll.

Und jetzt verrate mir noch, warum ein 32-Bit-Installer keinen 64-Bit-Kernel installieren können soll.

[wanne]

Ich habe ja schon geschrieben das es geht isch sehe nur keinen Sinn darin alles doppelt auf eine CD zu packen statt 2 kleine anzubieten.

[NAB]

Ich habe ja schon geschrieben das es geht isch sehe nur keinen Sinn darin alles doppelt auf eine CD zu packen statt 2 kleine anzubieten.

Siehste ... und genau da kommt "multiarch" ins Spiel. Dann kannste nämlich ein- und dasselbe "kde-artwork"-Paket einmal für x86 und einmal für AMD64 benutzen.

[wanne]

und genau da kommt "multiarch" ins Spiel. Dann kannste nämlich ein- und dasselbe "kde-artwork"-Paket einmal für x86 und einmal für AMD64 benutzen.

Nein, genau das passiert nicht! Darauf wollte ich dich hinweisen. Du kannst nur beide prallel drauf installieren. Was außer einer vollen Festplatte keine Vorteile Bringt.

[NAB]

Stimmt, das geht _noch_ nicht.

Stimmt, das bringt dem Endanwender _noch_ keine Vorteile.

Das schrieb ich oben schon. Danke für die Wiederholung.

[wanne]

Stimmt, das geht _noch_ nicht.

Nein, das gienge schon heute anders macht aber keinen Sinn. Dann währen die Pakete halt doppelt so groß. Und 2 Programme auf der größe von einem Abzuspeichern ist halt unmöglich.
Irgend wann in vielleicht 10-20 Jahren wird dann tatsächlich einfach nur noch amd64 angeboten werden. Eine Mixtur wird es nie geben. (Und war auch nie die Absicht.) Was soll der Mist für Vorteile Bringen?

Stimmt, das bringt dem Endanwender _noch_ keine Vorteile.

Der Vorteil wird immer kleiner aber: Ich sehe z.B. unter Mageia oder Fedora massenhaft Leute, die in ihrem schnellen 64Bit System. Skype und in der Beta Steam installiert haben, ohne Ahnung von irgend was zu haben. Das ist ein Vorteil. So soll das unter debian nun auch laufen.
Wir haben hier unter debian massenhaft Nutzer die die i386 nutzen, nur weil ihnen das gerödel um Skype zu installieren zu blöd ist. Dann rechnet er halt ein drittel langsamer dafür kein Ärger ist ein fairer tausch. (Zumal die CPU sowieso fast nie ausgelastet ist.)

[NAB]

Stimmt, das geht _noch_ nicht.

Nein, das gienge schon heute anders macht aber keinen Sinn. Dann währen die Pakete halt doppelt so groß.

Du hast mir immer noch nicht erklärt, wo jetzt der Unterschied zwischen einem 32-Bit-Desktophintergrund und einem 64-Bit Desktophintergrund ist.

Aber das ging schon bei Squeeze, mit "architecture all".

Das AMD64-Paket für Wine ist jetzt übrigens sehr klein, also nix mit "doppelt so groß":
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676457

Schon jetzt sind die Entwickler angehalten, "doppelte" Dateien aus Bibliothekspaketen auszulagern:
http://wiki.debian.org/Multiarch/Implementation
was schlicht Platz auf den Servern von Debian spart. Davon hast du persönlich natürlich nix.

Solange du in deiner kleinen AMD64-Welt lebst, bietet dir "multiarch" aber sowieso keine Vorteile. Spannend wird es, wenn du z.B. ARM-Bibliotheken installieren kannst, um deine ARM-Software unter AMD64 zu entwicklen und unter qemu zu testen.

Solange du nur Skype laufen lassen willst, hast du davon natürlich auch nix. Hat auch niemand behauptet. Das ging schon vorher. Vielleicht geht's jetzt etwas bequemer.

Noch bequemer geht's übrigens unter Windows. Da ist die Skype-Version auch viel neuer ^^

[wanne]

@NAB: Es gibt unterschiede zwichen ausführbaren Programmen und Bildern oder anderen Daten. Daten sind überall gleich und wahren das auch schon immer größtenteils. (Teilweise sind daten auf bestimmte architekturen obtimiert damit sie da besonders schnell gelesen werden können. Aber das ist die Ausnahme.)
Daten waren schon immer in Paketen ohne Architektur und konnten überall unabhönig von der Architektur installiert werden.
Für ausführbare Programme gilt:
Du wirs niemals ein arm Programm auf einem x86 Prozessor ausführen. PUNKT! Auch nicht in 100 Jahren.
Du kanns vielleicht irgend wann einen Interpreter schreiben, der das arm Programm während der "Ausführung" in x86 Befehle übersetzt. Aber auch dazu muss dann wenigstens der Interpreter in x86 sein und sinnvoll ist das auch nicht. (Ich hoffe mir bleiben jetzt die Skripter vom Hals die mir erklären dass NODE.JS nur noch 20 mal langsamer ist und man deswegen nicht mehr nativ schreiben soll.) Aund ausführen tust du eben wieder nur das generierte x86.
Nun zu deinem WINE. In 64Bit Windows gibt es nicht. (Abgesehen von irgendwelchen aufgebohrten XP Versionen.) Windows bringt immer alles einmal in 64Bit mit (Im Ordner System32) und einmal in 32Bit (Im Ordner WOW64). (Das ist einer der Gründe warum Windows bei einer minimalinstallation 40GiB groß ist und Linux nur 600KiB)
Deswegen macht das auch das WINE Paket so. Das 64Bit-Paket ist nur ein wrapper deswegen ist der so klein. Die eigentlichen Anwendungen sind da: /usr/lib/i386-linux-gnu/wine/wine.bin und ist eine 32Bit Anwendung. Die 32Bit libs braucht. In aktuelleren wine Versionen gibt es tatsächlich 2 mal wine, einmal 64Bit und ein mal 32Bit.

[NAB]

(Teilweise sind daten auf bestimmte architekturen obtimiert damit sie da besonders schnell gelesen werden können. Aber das ist die Ausnahme.)
Daten waren schon immer in Paketen ohne Architektur und konnten überall unabhönig von der Architektur installiert werden.

Siehste ... und genau da wird's dann spannend ... mit "multiarch" kannst du nämlich genau angeben, welche Architekturen von einem Paket alle abgedeckt werden. Und ich vermute mal, z.B. die "bookmarks.html" aus dem Firefox-Paket dürfte auf vielen Architekturen identisch aussehen:
http://packages.debian.org/wheezy/amd64 ... l/filelist
Die muss dann nur in einem Paket sein, das mehrere Architekturen abdeckt.
Das ist eine Verfeinerung von "alle" Architekturen.

Du wirs niemals ein arm Programm auf einem x86 Prozessor ausführen. PUNKT! Auch nicht in 100 Jahren.

Man, wanne, und in welchem Jahrhundert lebst du?
http://de.wikipedia.org/wiki/QEMU

Nun zu deinem WINE. In 64Bit Windows gibt es nicht. (Abgesehen von irgendwelchen aufgebohrten XP Versionen.) Windows bringt immer alles einmal in 64Bit mit (Im Ordner System32) und einmal in 32Bit (Im Ordner WOW64). (Das ist einer der Gründe warum Windows bei einer minimalinstallation 40GiB groß ist und Linux nur 600KiB)
Deswegen macht das auch das WINE Paket so. Das 64Bit-Paket ist nur ein wrapper deswegen ist der so klein. Die eigentlichen Anwendungen sind da: /usr/lib/i386-linux-gnu/wine/wine.bin und ist eine 32Bit Anwendung. Die 32Bit libs braucht. In aktuelleren wine Versionen gibt es tatsächlich 2 mal wine, einmal 64Bit und ein mal 32Bit.

Nachdem du jetzt die Architektur, die Wine emuliert, mit der Architektur durcheinandergebracht hast, auf der Wine läuft, erkläre mir doch mal, warum es in Squeeze noch ein Wine-Paket für AMD64 gab:
http://packages.debian.org/squeeze/wine-bin
und in Wheezy auf einmal nicht mehr:
http://packages.debian.org/wheezy/wine-bin
Ich dachte, durch multiarch hat man jetzt alle Pakete doppelt?

[wanne]

Man, wanne, und in welchem Jahrhundert lebst du?
http://de.wikipedia.org/wiki/QEMU

Ich habe dir das extra schön erklärt. QEMU führt keinen Code einer architektur aus sondern übersetzt lediglich live. Sowas nennt sich emulator.

Nachdem du jetzt die Architektur, die Wine emuliert, mit der Architektur durcheinandergebracht hast, auf der Wine läuft, erkläre mir doch mal, warum es in Squeeze noch ein Wine-Paket für AMD64 gab.

Du hast die Erklärung sogar selbst zitiert. Windows gibt's nicht alleine für 64Bit also auch kein wine mehr. Wine will wie Windows sein und hällt es gleich.

[NAB]

Ich habe dir das extra schön erklärt. QEMU führt keinen Code einer architektur aus sondern übersetzt lediglich live. Sowas nennt sich emulator.

Fein, also führt letztendlich ein AMD64-System ARM-Code aus. Und woher kommt dieser Code?

Du hast die Erklärung sogar selbst zitiert. Windows gibt's nicht alleine für 64Bit also auch kein wine mehr. Wine will wie Windows sein und hällt es gleich.

Ich habe die Erklärung in der Tat schon geliefert, aber du hast sie nicht verstanden.

Das wine-bin-Paket für AMD64 ist gestrichen worden, weil sich jetzt das wine-bin-Paket aus i386 unter AMD64 installieren lässt. Dank "multiarch".

Wine64 ist ein anderes Paket:
http://packages.debian.org/de/wheezy/wine64-bin

[wanne]

Fein, also führt letztendlich ein AMD64-System ARM-Code aus. Und woher kommt dieser Code?

Nein, Ein AMD64 System fürht AMD64-Code aus. Ob du den jetzt selber assemblert, zufällig generieren lassen, aus einer Hochsprache compiliert, oder eben aus einer anderen Sprache übersetzen lassen hast ist dem System natürlich völlig wurst. Nur das für gewöhlich ersterer relativ effizient ist und letzterer nicht. Bei jedem Übersetzungsvorgang wird halt im Normalfall irgend was mehr spezifiziert als vorher. Und da man das beim nächsten Übersetzen mal nicht mehr wegwerfen kann weil man ja nicht weiß ob das absicht war oder halt generiert wurde wird das halt jedes mal ineffizienter und größer. Deswegen will man das nicht und übersetzt für jede Architektur das Orginal. (Das macht z .B. Gentoo. Aber auch für dpkg und rpm gibt es source Pakete, die man sich prinzipiell installieren kann. Auch wenn das nicht der sinn von denen ist.) Den schon übersetzen Code nochmal zu übersetzen ist einfach nur schwachsinnig. (Esseiden man kommt an das Orginal nicht dran. Was bei Opensoruce Software nie de Fall ist) Da aber auch der Übersetzungsvorgang selbst rechenleistung braucht. Macht man das gerne einmal für alle. Da kommen dann binärpakte raus. Binärpakete haben nur den Sinn effizienter als sourcepakete zu sein. Sie zu interpretieren ist absolut schwachinnig. Und keiner außer dir wird je auf die Idee kommen.

Du hast die Erklärung sogar selbst zitiert. Windows gibt's nicht alleine für 64Bit also auch kein wine mehr. Wine will wie Windows sein und hällt es gleich.

Das wine-bin-Paket für AMD64 ist gestrichen worden, weil sich jetzt das wine-bin-Paket aus i386 unter AMD64 installieren lässt. Dank "multiarch".

Guck mal da: http://packages.debian.org/wheezy/wine64-bin.

[4A4B]

Du hast die Erklärung sogar selbst zitiert. Windows gibt's nicht alleine für 64Bit also auch kein wine mehr. Wine will wie Windows sein und hällt es gleich.

Das wine-bin-Paket für AMD64 ist gestrichen worden, weil sich jetzt das wine-bin-Paket aus i386 unter AMD64 installieren lässt. Dank "multiarch".

Guck mal da: http://packages.debian.org/wheezy/wine64-bin.

Das Paket installiert kein 64bittiges Wine, sondern nur ein Tool, das Anweisungen gibt, wie man Multiarch einrichtet, um ein 32bittiges Wine zu installieren:

This package provides instructions for installing 32-bit wine on 64-bit systems.

[wanne]

Das Paket installiert kein 64bittiges Wine, sondern nur ein Tool, das Anweisungen gibt, wie man Multiarch einrichtet, um ein 32bittiges Wine zu installieren:

Genau wie das alte wine für amd64. Geändert hat sich da nichts. Es gibt in den Debianquellen kein wine für 64Bit. Das es pakete gibt auf denen die falsche Architektur drauf steht ist was anderes. (Genausowenig wie steam ein 64Bit Programm ist nur weil 64Bit drauf steht.)
Und den Vorteil hast du ja schon genannt. Es ist jetzt viel einfacher einen paket eine anderen Architektur zu installiern.

Und das mit quell und Zielarchitektur kannst du bei wine im übrigen nicht wo einfach auseinander halten. Es wird wohl nie ein 32Bit wine geben, das 64Bit Programme ausführt. Ist eben kein Emulator. Und umgekehrt geht das zwar ist aber nicht ganz einfach gewesen wine64 macht einiges anderes als wine. (Das hat aber noch keinen Einzug in die Debianquellen gefunden.) Aber du wirst sehen das es irgend wann auch echte 64Bit wine-Pakete geben wird. – Die werden aber nicht auf 32Bit portierbar sein. Das mit wine ist halt dank der Arcitekur von Windows was besonderes. Das ist nicht ohne weiteres portierbar.
Deswegen nicht 2 mal das gleiche Paket in beiden Architekturen. Das wollte ich dir erklären.
Das hat aber gar nichts damit zu tun das das jetzt in einem Paket steckt. Da gab es nie 2.

[NAB]

Fein, also führt letztendlich ein AMD64-System ARM-Code aus. Und woher kommt dieser Code?

Nein, Ein AMD64 System fürht AMD64-Code aus. Ob du den jetzt selber assemblert, zufällig generieren lassen, aus einer Hochsprache compiliert, oder eben aus einer anderen Sprache übersetzen lassen hast ist dem System natürlich völlig wurst.

Fein. Nachdem du noch ein wenig mehr oder weniger schwachsinnig am Thema vorbei über Assembler und Codeoptimierung geredet hast, könntest du mir vielleicht endlich verraten, wo der ARM-Code herkommt, den das AMD64-System ausführt.

Dass er dabei stinkend langsam ist, ist mir dabei egal ... hauptsache, es läuft schnell genug, genau wie bei meinem Amiga-Emulator.

Guck mal da: http://packages.debian.org/wheezy/wine64-bin.

Dass du den Link von mir nochmal wiederholst, trägt irgendwie auch nicht zum Thema "multiarch" bei.

Das Paket installiert kein 64bittiges Wine, sondern nur ein Tool, das Anweisungen gibt, wie man Multiarch einrichtet, um ein 32bittiges Wine zu installieren:

Das geht zwar auch völlig am Thema vorbei, aber die seltsame Paketbeschreibung ist mir auch aufgefallen. Hast du das mal ausprobiert? Haben die da allen Ernstes ein Binary reingepackt, das nur einen Erklärungstext anzeigt? ^^

[wanne]

Fein. Nachdem du noch ein wenig mehr oder weniger schwachsinnig am Thema vorbei über Assembler und Codeoptimierung geredet hast, könntest du mir vielleicht endlich verraten, wo der ARM-Code herkommt, den das AMD64-System ausführt.

Nein, zum 10ten mal dein System führt keinen ARM-Code aus.
Du übersetzt nur mit dem zwichenprodukt ARM-Code. Im zweifelfall sieht das dann irgendwie so aus:
C-Code->ARM-Binary->AMD64-Binary
C-Code->AMD64-Binary
Das macht im Prinzip keinen Unterschied. Nur das obiges im Moment so etwa 10-100 mal mehr Rechenleistng brauch. – Und zwar bei jeder ausführung.
Außerdem hat man einen sehr komplexen Emulator dazwischen der praktisch immer Fehler verursacht. C ist so, dass es sehr gut zu übersetzen ist ARM eher nicht.

Dass er dabei stinkend langsam ist, ist mir dabei egal ... hauptsache, es läuft schnell genug, genau wie bei meinem Amiga-Emulator.

Es kann schon Einsatzzwecke geben, wo das mehr oder weniger egal ist aber dann kann man immernoch stromsparen. Die Frage ist einfach warum du dir rechhenleistung und potentielle Fehler einhandeln willst, wo es auch viel einfacher geht indem du einfach direkt übersetzt ohne den Zwischenschritt des ARM-Codes.

Guck mal da: http://packages.debian.org/wheezy/wine64-bin.

Dass du den Link von mir nochmal wiederholst, trägt irgendwie auch nicht zum Thema "multiarch" bei.

Das geht zwar auch völlig am Thema vorbei, aber die seltsame Paketbeschreibung ist mir auch aufgefallen. Hast du das mal ausprobiert? Haben die da allen Ernstes ein Binary reingepackt, das nur einen Erklärungstext anzeigt? ^^

Keine Binary ein shellscript. Und nein, das geht ganz und gar nicht am Thema vorbei. Es hat genau die gleiche Aufgabe wie das alte wine-bin:amd64. Dem amd64 Nutzer erleichtern ein i386 Paket zu installeren.
Es hat sich also nichts geändert. Nur das Paket wurde umbenannt und die erleichterung verändert. Statt das i386 Paket nochnmal selbst mitubringen, hat man eine erklärung reingebaut, wie man sich das richtige i386 Paket holt.

[NAB]

Fein. Nachdem du noch ein wenig mehr oder weniger schwachsinnig am Thema vorbei über Assembler und Codeoptimierung geredet hast, könntest du mir vielleicht endlich verraten, wo der ARM-Code herkommt, den das AMD64-System ausführt.

Nein, zum 10ten mal dein System führt keinen ARM-Code aus.

Schau, das Thema hier ist Multiarch und nicht, dass du Emulatoren scheiße findest, glaubst dass man sie nicht fehlerfrei erstellen kann oder dass AMD64-Prozessoren praktischer Weise auch Intel-x86er Code ausführen können. Ich mag dich gar nicht mit der Idee konfrontieren, dass AMD eventuell Prozessoren rausbringen könnte, die neben AMD64 auch den ARM-Befehlssatz verstehen, das würde bei dir ja elementare Glaubensgrundsätze erschüttern.

Somit möchte ich einfach wissen, woher denn der ARM-Code kommt, den ich auf meinem AMD-64-System unter Debian ausführe. Der Stromverbrauch ist mir dabei Scheiß egal ... nehmen wir mal an, ich entwickele für ARM und verdiene dabei soooooviel Zaster, dass ich mir die paar Gigawatt extra locker leisten kann.

[towo]

Den ARM-Code führt qemu aus.
Aber mal abgesehen davon hat das absolut gar nichts mit Multiarch zu tun.
Man konnte schon immer ARM-Binarys auf einem x86-System per qemu benutzen.