Hallo,
bei der Kompilierung des SDCC Compilers und dessen Installation fiel mir
auf, dass er sich nur noch mit "sudo make install" installieren liess.
configure und make liefen auch als User durch. Mit normalen Userrechten
gab es einen Abruch, dass der SDCC irgendeine Lib nicht nachladen kann.
Das installierte SDCC lässt sich fuers Kompilieren wiederum auch nur
noch unter root benutzen, alles andere verweigert er, dass er angeblich
einen C Source aus /usr/local/share/sdcc/lib.... nicht nachladen kann.
Was ist da strubbelig? Ich bin sehr vorsichtig die Rechte eines
Systemordners mit chmod o+r -R * mal eben zu überschreiben, damit habe
ich mir mal ein ganzes System zerschossen.
Der angemeckerte Pfad usr..... lässt sich als User sauber betreten,
gehört zwar root aber others dürfen lesen.
Deinstallation habe ich gemacht mit make uninstall und danach
Neuinstallation, bringt aber nichts.
Woher hast du den Quelltext? Ist er ein offizielles Release, einen
Nightly-Build bzw. gar per git clone den aktuellen Stand geholt?
Es könnte, wenn letztere zwei Optionen, ein Fehler im Install Script
sein.
Christian J. schrieb:> Der angemeckerte Pfad usr..... lässt sich als User sauber betreten,> gehört zwar root aber others dürfen lesen.
Schau mal, welche Rechte die einzelnen Dateien bzw. die angemeckerte
Datei haben bzw. hat.
2⁵ schrieb:> Woher hast du den Quelltext? Ist er ein offizielles Release,
Normaler Release von 2015 aus den Snapshot Archives. Bei den neuen
Versionen haben die so viel geändert bei den "spezifischen
Erweiterungen", dass ich meine Sourcen nicht mehr ans Laufen kriege.
Christian J. schrieb:> bei der Kompilierung des SDCC Compilers und dessen Installation fiel mir> auf, dass er sich nur noch mit "sudo make install" installieren liess.> configure und make liefen auch als User durch. Mit normalen Userrechten> gab es einen Abruch, dass der SDCC irgendeine Lib nicht nachladen kann.
So weit, so normal. Ein normales "make install" schreibt Dateien in
Unterverzeichnisse wie /usr, und da dürfen normale Benutzer natürlich
nicht einfach hinschreiben. Wenn das configure-Skript das unterstützt,
kann man ihm mit dem Schalter "--prefix=<verzeichnis>" ein <verzeichnis>
mitgeben, wo er die Software hininstallieren soll.
> Das installierte SDCC lässt sich fuers Kompilieren wiederum auch nur> noch unter root benutzen, alles andere verweigert er, dass er angeblich> einen C Source aus /usr/local/share/sdcc/lib.... nicht nachladen kann.>> Was ist da strubbelig? Ich bin sehr vorsichtig die Rechte eines> Systemordners mit chmod o+r -R * mal eben zu überschreiben, damit habe> ich mir mal ein ganzes System zerschossen.
Merkwürdig -- bei einem 'o-r' würde ich das ja noch verstehen, aber bei
einem 'o+r'? Das kann höchstens dort etwas "kaputtmachen", wenn ein
Dienst (wie zum Beispiel SSH) auf die Permissions seiner Dateien achtet,
aber dann ist nicht etwas das System zerschossen, sondern dann muß man
nur die Permissions der betreffenden Dateien wieder geradebiegen.
Darüber hinaus kann man Permissions natürlich nicht nur rekursiv für
einen ganzen Verzeichnisbaum vergeben, sondern (dann ohne "-R")
natürlich auch für einzelne Dateien.
> Der angemeckerte Pfad usr..... lässt sich als User sauber betreten,> gehört zwar root aber others dürfen lesen.>> Deinstallation habe ich gemacht mit make uninstall und danach> Neuinstallation, bringt aber nichts.
Klassische Windows-Strategien wie Reboot oder Neuinstallation klappen
unter Linux und anderen UNIX-artigen Systemen meistens nicht. Unter UNIX
sind Fehler nämlich fast immer reproduzierbar, und ein Reboot oder eine
stupide Neuinstallation machen dann genau denselben Fehler eben wieder.
Deswegen ist es unter UNIX-artigen Systemen meistens zielführender, die
Fehler zu finden und zu korrigieren. ;-)
Tipp: mach doch einfach mal ein 'ls -lR /usr/local/share/sdcc/', als
ganz normaler Benutzer. Dann solltest Du schnell sehen, wo das Problem
liegt -- vermutlich hat das Installationsskript von SDCC einfach nur
irgendwo die Permissions nicht richtig gesetzt oder Dateien vergessen.
Karl Käfer schrieb:> Tipp: mach doch einfach mal ein 'ls -lR /usr/local/share/sdcc/', als> ganz normaler Benutzer. Dann solltest Du schnell sehen, wo das Problem> liegt -- vermutlich hat das Installationsskript von SDCC einfach nur> irgendwo die Permissions nicht richtig gesetzt oder Dateien vergessen.
Ok, werde ich gleich mal ausprobieren, kann ja per Smartphone per ssh
auf den rechner zu hause.....
Ok... habs:
Öffnen von Verzeichnis /usr/local/share/sdcc/non-free/.... nicht
möglich.
Und noch hundert gleichartige Meldungen für das /lib Verzeichnis. Viele
andere können aber betreten werden. Gehören auch klar zum sdcc.
Vom Smartphone aus aber mühselig jetzt auf dem Mäuseklavier, heute abend
mal am Rechner schauen. Entweder stimmt der User nicht oder aber die
Berechtigung.
sudoers zb achtet auf seine Berechtigung, eimal versaubeutelt und Du
bist ausgeschlossen.
sudo make install ist aber ok?
Ich werde also wohl beides durchlaufen lassen müssen:
sudo chown -R user:user /usr/local.....
sudo chmod ugo+rx -R /usr/local
dass sowohl Dateien als auch Verzeichnisse eingenordet werden. Das sind
hunderte Files und Unterverzeichnisse, per Hand ein sinnloses
Unterfangen.
Kommt vielleicht auch von dem Hin udn Her Kopieren zwischen FAT32, NTFS
und EXT4 Systemen, da da Permissions verloren gegangen sind.
Christian J. schrieb:> Öffnen von Verzeichnis /usr/local/share/sdcc/non-free/.... nicht> möglich.> Und noch hundert gleichartige Meldungen für das /lib Verzeichnis. Viele> andere können aber betreten werden. Gehören auch klar zum sdcc.
/lib? Du meinst /usr/local/lib, oder?
> Vom Smartphone aus aber mühselig jetzt auf dem Mäuseklavier, heute abend> mal am Rechner schauen. Entweder stimmt der User nicht oder aber die> Berechtigung.
Die Berechtigungen. Normale Dateien sollten "root" gehören und für group
und others nur lesbar, für "root" hingegen (think Updates) beschreibbar
sein (u=rw,go=r bzw. 0644). Ausführbare Dateien undVerzeichnisse sollten
"root" gehören und für group und others les- und ausführbar und für
"root" auch beschreibbar sein (u=rwx,go=rx bzw. 0755).
> sudoers zb achtet auf seine Berechtigung, eimal versaubeutelt und Du> bist ausgeschlossen.
Ja, aber wer chmod(1) (oder chown(1) oder ghgrp(1)) rekursiv auf /etc
anwendet, sollte mit Windows nicht unter vier Wochen bestraft werden.
> sudo make install ist aber ok?
Ja, unbedingt. Wie sonst soll install(1) die Dateien und Verzeichnisse
an einen Ort installieren, den nur "root" beschreiben darf?
> Ich werde also wohl beides durchlaufen lassen müssen:> sudo chown -R user:user /usr/local.....> sudo chmod ugo+rx -R /usr/local
Bloß nicht! find(1) ist Dein Freund ("-type", "-exec", ggf. "-perm"),
vielleicht wie im folgenden Beispiel. Die Binaries von sdcc sollten eh
in /usr/local/bin gelandet und korrekt ausführbar sein.
Ok, ein
sudo chmod ugo+rx -R * in dem gesamten sdcc Verzeichnis hat es behoben
:-)
Tuts wieder als User, auch wenn jetzt villeicht zu vieles als X
deklariert ist, schadet ja nicht.
Deinen Term habe ich mir mal kopiert, sieht nützlich aus.
schwitz
Wenn der sdcc bloss nicht so entsetzlich langsam wäre...... 4 Minuten
für 18 Sourcen :-(((((
Christian J. schrieb:> sudo chmod ugo+rx -R * in dem gesamten sdcc Verzeichnis hat es behoben
Warum mit dem Florett fechten, wenn man auch den Hammer benutzen kann...
;-)
> Tuts wieder als User, auch wenn jetzt villeicht zu vieles als X> deklariert ist, schadet ja nicht.>> Deinen Term habe ich mir mal kopiert, sieht nützlich aus.
Sogar unter den vielen leistungsfähigen Shellwerkzeugen ist find(1)
immer noch ein echtes Highlight. ;-)
> Wenn der sdcc bloss nicht so entsetzlich langsam wäre...... 4 Minuten> für 18 Sourcen :-(((((
Kann man das nicht mit einem sauberen Makefile und "-j" parallelisieren?
(Und, wenn ich fragen darf: was nimmst Du nicht den guten alten GCC?)
Sheeva P. schrieb:> (Und, wenn ich fragen darf: was nimmst Du nicht den guten alten GCC?)
Weil der Z80 vom gcc leider nicht unterstützt wird. :-)
Und ja, je nach Einstellung für den Registerallokator kann man den SDCC
beliebig langsam machen. Oder schneller, wenn schlechterer Code
akzeptabel ist.
S. R. schrieb:> Weil der Z80 vom gcc leider nicht unterstützt wird. :-)
Da sollte dringend mal eine Petition für unterzeichnet werden bei
change.org !
Ginge das so einfach? Müsste doch, die brauchen doch bloss die Mnemonics
Tabellen im Target austauschen und fertig wäre das Ding. Der GCC kann
doch sonst jeden Museums Prozessor unterstützen: VAX, PDP-11...
staubwisch War der nicht auch der Zentralrechner der russ. SS-20
Raketen?
Christian J. schrieb:>> Weil der Z80 vom gcc leider nicht unterstützt wird. :-)> Ginge das so einfach?
Nein.
Der Z80 ist eine Akku-Architektur mit ziemlich unorthogonalem
Befehlssatz und teilweise sehr komplexen Befehlen (z.B. LDIR). Es gibt
zwei getrennte Adressräume (Speicher und I/O), und die meisten Systeme
nutzen Bankswitching. Die Register sind unterschiedlich. Dafür
automatisch guten Code generieren ist sehr schwierig, und teilweise ohne
Compiler-Extensions schlicht unmöglich.
Sowohl PDP-11, VAX als auch AVR (um in der 8 Bit-Welt zu bleiben) sind
Architekturen mit sehr orthogonalem Befehlssatz, und gut geeignet für
Hochsprachen wie C. Der Z80 ist das nicht.
SDCC zielt auf Architekturen ab, die gcc nichtmal näher anschauen
möchte, und dafür gibt es gute Gründe. Allein deswegen ist SDCC schon
beeindruckend.
