Forum: Compiler & IDEs SDCC lässt sich mit Userrechten nicht mehr aufrufen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Christian J. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
2⁵ schrieb:
> git clone

bzw. svn

von Christian J. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Karl Käfer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christian J. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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
von Christian J. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :-(((((

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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?)

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christian J. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.