Hallo Besucher, der Thread wurde 2,2k mal aufgerufen und enthält 12 Antworten

letzter Beitrag von Mac Bacon am

ACME für ARM-Prozessor

    Hallo zusammen,


    ich suche schon eine Weile nach einem Cross-Assembler für den Raspberry Pi 3 -> C64. ACME habe ich schon unter Windows benutzt, deshalb:


    Wie ich über ACME gelesen habe wurde selbiger ja ursprünglich für das RISC OS entwickelt. Und RISC OS für einen ARM-Prozessor. Kann ich daraus schließen, dass ACME auf einem Raspi zu kompilieren ist? Das eingesetzte Betriebssystem soll allerdings Raspbian und nicht RISC OS sein.


    Wenn das nicht geht, kann mir jemand alternative Cross-Assembler aufzeigen? Tante Goo*** bringt leider so ziemlich Alles und Nichts als Antwort. Vielleicht verwende ich auch nur die falschen Suchbegriffe ...

    Beim Sourcecode ist ja ein normales Linux-Makefile das gcc verwendet dabei, daher sollte es kein Problem sein, es auf dem Raspi unter Linux zu kompilieren. Oder willst Du es wirklich unter RiscOS verwenden?

    Danke für die Antwort. Und nein, ich möchte gerade nicht RiscOS sondern Raspbian (Debian-Abkömmling) benutzen. Mir ist nur nicht klar, ob die Source Probleme wegen des ARM-Prozessors bereitet. Nicht dass ich am Ende stundenlang tausend Abhängigkeiten auflösen muss und das Ganze am Ende dann doch scheitert weil nur für x86 bzw Intel.


    Edit: Huch, jetzt war ich zu langsam mit der Antwort. Vielen Dank an alle, dann wird ich das mal probieren. Und freu mich schon wenn's klappt. Mit Geany als Editor/IDE hatte ich unter Windows gute Erfahrung gemacht.

    Hallo,


    ich habe nach der obigen Methode auch gerade ACME auf einem Raspberry Pi 3B mit dem aktuellen "Raspbian Buster Lite" vom 10.07.2019 installiert, da bei mir mit "sudo apt-get install acme" nur die Version 0.96.2 installiert wurde.


    Das Repository auf Github wurde zwar im Februar 2019 das letzte Mal aus dem SVN-Repository übernommen, enthält aber wenigstens den Stand 0.96.4 (allemal besser als 0.96.2...).


    Allerdings musste ich im Makefile das Verzeichnis für das Executable ändern:

    Von alt: BINDIR = /usr/local/bin

    Auf neu: BINDIR = /usr/bin


    Ohne diese Änderung konnte ich ACME nur per "sudo acme --version" aufrufen, mit der Änderung klappt es auch als normaler User einfach mit "acme --version".


    Ist das normal/richtig so, oder habe ich was falsch gemacht?


    Gruß

    Thomas


    PS: Ich habe auch ein "sudo make userinstall" gefunden, aber das würde ja ACME nur im lokalen Userverzeichnis installieren...

    Zitat von Freak

    Allerdings musste ich im Makefile das Verzeichnis für das Executable ändern:

    Von alt: BINDIR = /usr/local/bin

    Auf neu: BINDIR = /usr/bin


    Ohne diese Änderung konnte ich ACME nur per "sudo acme --version" aufrufen, mit der Änderung klappt es auch als normaler User einfach mit "acme --version".


    Ist das normal/richtig so, oder habe ich was falsch gemacht?

    Man kann das durchaus so machen, und im Augenblick ist das kein Problem, aber "normal/richtig" ist:

    /usr/bin wird vom System-Paketdienst verwaltet, in /usr/local/bin/ kommen hingegen alle Dinge, die der Admin am Paketsystem vorbei installiert hat. Da Dein System-Paketdienst ja ein ACME-Paket anbietet, Dir dies aber zu alt ist, liegt das potentielle Problem auf der Hand: Ein erneutes "sudo apt-get install acme" würde Dir Dein selbst erzeugtes Binary mit der älteren Version überschreiben. Liegen aber all Deine selbst erzeugten Sachen unter /usr/local, kann das nicht passieren.

    Welche Fehlermeldung kam denn bei dem Versuch mit /usr/local/bin? Fehlt dieses Verzeichnis evtl. einfach nur in Deinem Suchpfad? Gib in einer Konsole einfach mal "echo $PATH" ein, da sollten (tm) normalerweise /home/BENUTZERNAME/bin, /usr/local/bin und /usr/bin in dieser Reihenfolge auftauchen (zwischen evtl. noch ein paar anderen Einträgen).

    Zitat von enthusi

    Ich habe im homedir ein Verzeichnis 'bin'.

    Das ist auch im PATH. Das ist bei vielen Distros default.

    Dahin kopiere ich von Hand die executables nach dem compile.

    Also ohne Make install.

    Genau das macht ja "make userinstall".

    Zitat von Freak

    Ich habe auch ein "sudo make userinstall" gefunden, aber das würde ja ACME nur im lokalen Userverzeichnis installieren...

    Für die meisten Leute reicht das ja auch, oder administrierst Du ein System für mehrere Benutzer, die alle 6502 programmieren wollen? ;)


    ...und "sudo" bitte nur verwenden, wenn unbedingt nötig. Soll heißen: In diesem Fall nicht.

    Zitat von Mac Bacon

    Man kann das durchaus so machen, und im Augenblick ist das kein Problem, aber "normal/richtig" ist:

    /usr/bin wird vom System-Paketdienst verwaltet, in /usr/local/bin/ kommen hingegen alle Dinge, die der Admin am Paketsystem vorbei installiert hat. Da Dein System-Paketdienst ja ein ACME-Paket anbietet, Dir dies aber zu alt ist, liegt das potentielle Problem auf der Hand: Ein erneutes "sudo apt-get install acme" würde Dir Dein selbst erzeugtes Binary mit der älteren Version überschreiben. Liegen aber all Deine selbst erzeugten Sachen unter /usr/local, kann das nicht passieren.

    Welche Fehlermeldung kam denn bei dem Versuch mit /usr/local/bin? Fehlt dieses Verzeichnis evtl. einfach nur in Deinem Suchpfad? Gib in einer Konsole einfach mal "echo $PATH" ein, da sollten (tm) normalerweise /home/BENUTZERNAME/bin, /usr/local/bin und /usr/bin in dieser Reihenfolge auftauchen (zwischen evtl. noch ein paar anderen Einträgen).

    Hmmm...


    Ich habe jetzt nochmal das ganze ACME-Verzeichnis gelöscht (inklusive der Executables in /usr/bin und /usr/local/bin) und ACME ein zweites Mal aus den Quellen geladen und gebaut.


    Und jetzt geht es... Merkwürdig... Die Fehlermeldung beim ersten Versuch weiss ich natürlich nicht mehr, ich meine aber, er fand das Executable nicht...


    Die $PATH-Variable ist auch einigermaßen normal, fehlt nur "/home/USER/bin": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"


    Daraus folgere ich mal, dass ein "make userinstall" nichts bringen würde, weil der Suchpfad nicht auf das bin-Verzeichnis im home-Verzeichnis schaut. Ich müsste dann also noch die $PATH-Variable erweitern...


    Ich danke Dir auf jeden Fall für die Aufklärung!


    Gruß

    Thomas

    Ich habe mir ein eigenes Debian-Repository für selbst kompilierte ARM-Pakete eingerichtet (siehe mein Thread zu OpenCBM). Es soll ein Repository mit Schwerpunkt Retro-Tools sein. Besteht bei Euch Interesse, ACME in einer aktuellen Development-Fassung als Debian-Paket aus einem experimentellen Repository zu bekommen?


    EDIT: Ich hänge hier mal aktuelle Pakete von acme ran (eben gebaut - svn trunk r117) - alles ohne Gewähr und ungetestet: armhf müsste auf Raspberry Pi 3 (32bit) laufen.

    Zitat von Freak

    Die $PATH-Variable ist auch einigermaßen normal, fehlt nur "/home/USER/bin": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"

    Existiert das Verzeichnis denn? Falls nicht, leg es mal an und log Dich aus und wieder ein. Viele Login-Skripte nehmen das Verzeichnis nur dann in die PATH-Variable auf, wenn es auch vorhanden ist.