Kann der Code einfach für jede CPU-Architektur kompiliert werden?
Hallo zusammen,
ich habe einen PI mit der CPU ARMv7.
Nun gibt es viele Programme die ich auf einem 64Bit CPU verwendet habe nicht für die ARMv7 Architektur.
Ist es den so, dass man durch das Kompilieren vom Quellcode (viele der Tools die ich verwendet haben waren open source) das Tool dadurch auf seinem PI zum laufen bringen kann?
Ich würde beispielsweise den Atom-Editor darauf verwenden (8GB RAM hat der PI).
Das .deb Paket vom Hersteller ist aber nicht für ARMv7 ausgelegt.
Kann ich das Problem mit dem Kompilieren des Codes umgehen?
Lg
WinliCLI
ich habe einen PI mit der CPU ARMv7.
Nun gibt es viele Programme die ich auf einem 64Bit CPU verwendet habe nicht für die ARMv7 Architektur.
Ist es den so, dass man durch das Kompilieren vom Quellcode (viele der Tools die ich verwendet haben waren open source) das Tool dadurch auf seinem PI zum laufen bringen kann?
Ich würde beispielsweise den Atom-Editor darauf verwenden (8GB RAM hat der PI).
Das .deb Paket vom Hersteller ist aber nicht für ARMv7 ausgelegt.
Kann ich das Problem mit dem Kompilieren des Codes umgehen?
Lg
WinliCLI
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 654846
Url: https://administrator.de/forum/kann-der-code-einfach-fuer-jede-cpu-architektur-kompiliert-werden-654846.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
14 Kommentare
Neuester Kommentar
Hallo
Sollte selbererklärend sein
Alles DEB Pakete sind genannt, damit man den Programm-Code selber kompilieren kann, so auch auf einer ARM Architektur.
Oder du missbrauchst das Pi und bringst eine VM dort zum laufen !
Der weg des geringeren Widerstand ist es wohl den Code auf dem PI zu Übersetzen, und dann laufen zu lassen, als die kleine "Kiste" mit einer VM zu belasten
Sollte selbererklärend sein
Alles DEB Pakete sind genannt, damit man den Programm-Code selber kompilieren kann, so auch auf einer ARM Architektur.
Oder du missbrauchst das Pi und bringst eine VM dort zum laufen !
Der weg des geringeren Widerstand ist es wohl den Code auf dem PI zu Übersetzen, und dann laufen zu lassen, als die kleine "Kiste" mit einer VM zu belasten
Der Code ist ja auch in irgendeiner Programmiersprache erstellt worden. Es benötigt dann einen Compiler für dein Ziel-OS auf der Ziel-Architektur.
Das braucht es für alle Komponenten, die das Programm nutzt. Wenn du z.B. ein Programm in C schreibst, welches zur Ausführung Java benötigt (weil Programmteile davon in Java geschrieben sind), dann musst du auf den Rechner auch irgendwie Java bekommen.
Umso mehr das an die Hardware geht, umso schwieriger wird das.
Das braucht es für alle Komponenten, die das Programm nutzt. Wenn du z.B. ein Programm in C schreibst, welches zur Ausführung Java benötigt (weil Programmteile davon in Java geschrieben sind), dann musst du auf den Rechner auch irgendwie Java bekommen.
Umso mehr das an die Hardware geht, umso schwieriger wird das.
Hallo
Warum ? Auf einem PI ist Java sehr wohl verfügbar !
Pi ist eine ARM Architektur, und dafür gibt es alles was man benötigt um den Code für diesen ATOM-Editor neu zu kompilieren.
Warum ? Auf einem PI ist Java sehr wohl verfügbar !
Pi ist eine ARM Architektur, und dafür gibt es alles was man benötigt um den Code für diesen ATOM-Editor neu zu kompilieren.
Das war nur ein Beispiel. Es sollte zumindest mit allem gehen, wo die Funktionsweise der Programmiersprache und die Hardware bekannt sind. So könnte man da zumindest in der Theorie einen Compiler schreiben.
OpenJDK ist meines Wissens Open-Source, somit könnte da auch jemand einen Compiler für eine völlig neue Architektur schreiben.
OpenJDK ist meines Wissens Open-Source, somit könnte da auch jemand einen Compiler für eine völlig neue Architektur schreiben.
Keine Beispiele , der ATOM Editor läuft mit etwas Mühe sogar auf einem 3 er PI !
Wenn man mit der Denkweise eines wohl Windows Users auf Linux wechselt, dann ist es wohl eine überfordernde Frage, wie kann ich für "Null GELD" und "Null Handlungen abweichend vom Mausschupser-Aktivitäten" irgendwas machen !
Wenn er den Post vielleicht wo anders rein gestellt hätte, und neben der TO "Kann der Code einfach für jede CPU-Architektur kompiliert werden?" mal mit seinen weiteren Ausführungen verglichen ?
Wenn man sich keine SD Card für ein PI leisten kann, wo mal alle und diese möglichen Entwicklungsumgebungen und GUI aufspielt, und dann den fertigen Code nur auf die Arbeits-SD Überträgt ;) ???
Wenn man mit der Denkweise eines wohl Windows Users auf Linux wechselt, dann ist es wohl eine überfordernde Frage, wie kann ich für "Null GELD" und "Null Handlungen abweichend vom Mausschupser-Aktivitäten" irgendwas machen !
Wenn er den Post vielleicht wo anders rein gestellt hätte, und neben der TO "Kann der Code einfach für jede CPU-Architektur kompiliert werden?" mal mit seinen weiteren Ausführungen verglichen ?
Wenn man sich keine SD Card für ein PI leisten kann, wo mal alle und diese möglichen Entwicklungsumgebungen und GUI aufspielt, und dann den fertigen Code nur auf die Arbeits-SD Überträgt ;) ???
Du kannst jeglichen Code für ARM kompilieren, sofern es OS Projekte sind. Gegebenenfalls sind Anpassungen notwendig. Beachte aber, dass das bei größeren Anwendungen einige Zeit dauern kann und du das für JEDES Update erneut durchführen musst. Das macht in der Kombination im Alltag eher weniger Spaß, wenngleich es mit einem 4er nicht mehr so schlimm sein sollte wie mit den älteren RPIs (da haben manche Projekte etliche Stunden bis Tage kompiliert...)
Ich für meinen Teil habe mir lieber einen günstigen x86 Tiny gekauft, da ein normales xUbuntu drauf installiert und man kann bequem alle Pakete aus den Repos laden. Ist Alltagstauglicher fürs Nutzen von GUI Programmen, sofern es dir mehr um einen praktikabel Einsatz geht und nicht primär ums lernen.
Ich für meinen Teil habe mir lieber einen günstigen x86 Tiny gekauft, da ein normales xUbuntu drauf installiert und man kann bequem alle Pakete aus den Repos laden. Ist Alltagstauglicher fürs Nutzen von GUI Programmen, sofern es dir mehr um einen praktikabel Einsatz geht und nicht primär ums lernen.
Moin,
Solange die Programme in einer Hochsprache geschrieben sind und keinen architekturspezifische Maschinencode enthalten, bzw. der Code für die Zielarchitektur vorhanden ist, kann man I.d.R. auch alles auf dem Pi kaufen lassen, nachdem man selbst kompiliert hat.
Wenn man sich damit Mal grundlegend beschäftigt hat, ist das sogar Recht einfach zu handhaben.
lks
Solange die Programme in einer Hochsprache geschrieben sind und keinen architekturspezifische Maschinencode enthalten, bzw. der Code für die Zielarchitektur vorhanden ist, kann man I.d.R. auch alles auf dem Pi kaufen lassen, nachdem man selbst kompiliert hat.
Wenn man sich damit Mal grundlegend beschäftigt hat, ist das sogar Recht einfach zu handhaben.
lks
Zitat von @147448:
Hallo
Warum ? Auf einem PI ist Java sehr wohl verfügbar !
Pi ist eine ARM Architektur, und dafür gibt es alles was man benötigt um den Code für diesen ATOM-Editor neu zu kompilieren.
Hallo
Warum ? Auf einem PI ist Java sehr wohl verfügbar !
Pi ist eine ARM Architektur, und dafür gibt es alles was man benötigt um den Code für diesen ATOM-Editor neu zu kompilieren.
Vielleicht ein konkretes Beispiel. Du schreibst ein Programm in C. Verwendest aber Dot.Net.Framework for Desktop. Dann wird dir der Code auf einer Machine auf der Linux läuft wenig bringen auch wenn C auch dort laufen würde.
Zitat von @mayho33:
Vielleicht ein konkretes Beispiel. Du schreibst ein Programm in C. Verwendest aber Dot.Net.Framework for Desktop. Dann wird dir der Code auf einer Machine auf der Linux läuft wenig bringen auch wenn C auch dort laufen würde.
Zitat von @147448:
Hallo
Warum ? Auf einem PI ist Java sehr wohl verfügbar !
Pi ist eine ARM Architektur, und dafür gibt es alles was man benötigt um den Code für diesen ATOM-Editor neu zu kompilieren.
Hallo
Warum ? Auf einem PI ist Java sehr wohl verfügbar !
Pi ist eine ARM Architektur, und dafür gibt es alles was man benötigt um den Code für diesen ATOM-Editor neu zu kompilieren.
Vielleicht ein konkretes Beispiel. Du schreibst ein Programm in C. Verwendest aber Dot.Net.Framework for Desktop. Dann wird dir der Code auf einer Machine auf der Linux läuft wenig bringen auch wenn C auch dort laufen würde.
Dann nimmt man halt Mono als Ersatz für dot.net.
Abgesehen davon bietet auch MS Unterstützung on dot.net unter Linux.
lks
Zitat von @Lochkartenstanzer:
Dann nimmt man halt Mono als Ersatz für dot.net.
Abgesehen davon bietet auch MS Unterstützung on dot.net unter Linux.
lks
Dann nimmt man halt Mono als Ersatz für dot.net.
Abgesehen davon bietet auch MS Unterstützung on dot.net unter Linux.
lks
Natürlich! Aber die Frage ging ja in einer andere Richtung und meine Beispiel auch. Und du hast es weiter oben ja auch schon so kommentiert.
Kann man also Code der OS- und architektur-spezifische Elemente enthält auf einem anderen OS mit anderer Prozessor-Architektur kompilieren? Ad Hoc nein!
Hallo,
normalerweise ja.
Allerdings verwendet der Code u.U. auch Libraries, die ebenfalls im Quellcode vorliegen oder entsprechend compiliert sein müssen. Und es gibt tatsächlich Konstrukte, die einen Code architekturabhängig machen (z.B. Inline-Code, was heutzutage aber eher unüblich ist).
Jeder Prozessor und jede Architektur hat einen bestimmten Befehlssatz. Vorraussetzung wäre natürlich auch, dass das, was Du compilieren willst, mit dem Befehlssatz läuft. Z.B. wirst Du KVM nicht auf einer Möhre compiliert kriegen, deren Prozessor keine Virtualisierung kennt
Gruß,
Jörg
normalerweise ja.
Allerdings verwendet der Code u.U. auch Libraries, die ebenfalls im Quellcode vorliegen oder entsprechend compiliert sein müssen. Und es gibt tatsächlich Konstrukte, die einen Code architekturabhängig machen (z.B. Inline-Code, was heutzutage aber eher unüblich ist).
Jeder Prozessor und jede Architektur hat einen bestimmten Befehlssatz. Vorraussetzung wäre natürlich auch, dass das, was Du compilieren willst, mit dem Befehlssatz läuft. Z.B. wirst Du KVM nicht auf einer Möhre compiliert kriegen, deren Prozessor keine Virtualisierung kennt
Gruß,
Jörg
Das ist doch immer wieder so eine Kotze ( entschuldigt das Wort ) dass man nicht sauber Programmiert und sondern auf Systemspezifische Standard Programm Bibliotheken zurückgreift,und somit auch die eigene bevorzugte Programmiersprache verlässt !
Solange hier reine OOP unterwegs sind, die nur Windows kennen wird man keinen Konzens finden.
Solange hier reine OOP unterwegs sind, die nur Windows kennen wird man keinen Konzens finden.
Warum soll man(n) das Rad neu erfinden ?
Mal die ganz ehrliche Frage , die auf APIs und Programmbibliotheken abzielt.
Auch der VLC bringt für um unter WIN zu laufen eigene Schnittstellen mit, die in der gesamten Unixoiden Welt genutzt werden . Und VLC ist wohl auch unter WIN einer der verbreitesten Medien-Player !
Die LIB-DLL Übersetzung GTK gibt es gleich gratis dazu !
Nun ist es wohl nur noch eine reine Aufwands- und Verständnisfrage, wie langesich WIN noch im Desktop Bereich halten wird, zumal immer mehr professionelle Anbieter entweder auf die WEB Console beschränken, oder darüber die zT Open Source Software auch für WIN bereitstellen.
Schlimm, schlimm, wenn man nur mal weiter denken würde.
Würde mal alle Unixoiden Geräte mit einem Ausschaltbefehl wirklich ausschalten können, was wäre dann Windows ? Nicht viel mehr wie MS-DOS von der Diskette gestartet !
Kein Mensch braucht um einen 10 seitigen Brief zu schreiben, einen GIGANTISMUS - Prozessor aus dem Hause Intel, mehr als 4 oder 8 GB RAM, und auch kein Betriebssystem wie Windows was mit der Office Suite mehr als 4 GB RAM fordert !
Das gesamte Machwerk um WINDOWS kann heute keiner mehr durchleuchten ! Es ist neben das es ein Speicherfressendes Konstrukt ist, und die Software noch mehr Ressourcen fordert eine TOD Geburt !
Nur solange die User, die Massenware von der Stange kaufen, werden erschreckt, wenn nicht WINDOWS draufsteht !
Mal die ganz ehrliche Frage , die auf APIs und Programmbibliotheken abzielt.
Auch der VLC bringt für um unter WIN zu laufen eigene Schnittstellen mit, die in der gesamten Unixoiden Welt genutzt werden . Und VLC ist wohl auch unter WIN einer der verbreitesten Medien-Player !
Die LIB-DLL Übersetzung GTK gibt es gleich gratis dazu !
Nun ist es wohl nur noch eine reine Aufwands- und Verständnisfrage, wie langesich WIN noch im Desktop Bereich halten wird, zumal immer mehr professionelle Anbieter entweder auf die WEB Console beschränken, oder darüber die zT Open Source Software auch für WIN bereitstellen.
Schlimm, schlimm, wenn man nur mal weiter denken würde.
Würde mal alle Unixoiden Geräte mit einem Ausschaltbefehl wirklich ausschalten können, was wäre dann Windows ? Nicht viel mehr wie MS-DOS von der Diskette gestartet !
Kein Mensch braucht um einen 10 seitigen Brief zu schreiben, einen GIGANTISMUS - Prozessor aus dem Hause Intel, mehr als 4 oder 8 GB RAM, und auch kein Betriebssystem wie Windows was mit der Office Suite mehr als 4 GB RAM fordert !
Das gesamte Machwerk um WINDOWS kann heute keiner mehr durchleuchten ! Es ist neben das es ein Speicherfressendes Konstrukt ist, und die Software noch mehr Ressourcen fordert eine TOD Geburt !
Nur solange die User, die Massenware von der Stange kaufen, werden erschreckt, wenn nicht WINDOWS draufsteht !