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.
1 | find /usr/local/share/sdcc \( -type d -and -exec chmod 755 {} \; \) -or \( -type f -and -exec chmod 644 {} \; \)
|
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.