Hallo, ich versuche verzweifelt Free Pascal auf dem Raspberry Pi (B) mit Wheezy-Raspbian zu installieren. Entsprechend den Anweisungen unter http://wiki.freepascal.org/Lazarus_on_Raspberry_Pi/de habe ich es mit "sudo apt-get install fpc" ausgeführt. Die Installation lief soweit fehlerfrei, mit "fp" kann die IDE gestartet werden. Leider gibt es jedoch keine Directory-Einträge für die Units (in der IDE unter Options / Directories). Ein eifaches "WriteLn ('Hello World');" funktioniert zwar, aber das Einbinden der Units (z.B. uses ptc) ergibt die Fehlermeldung, daß die Unit nicht gefunden wurde. Warum werden die Pfade bei der Installation nicht mit eingetragen? Wo finde ich die Pfadangaben? Könnte mir ein Linux-Kenner bitte weiterhelfen? (Es geht nur um Free Pascal, ohne Lazarus). Vielen Dank! Berry
Warst Du da schon? http://wiki.lazarus.freepascal.org/Unit_not_found_-_How_to_find_units/de Sonst mach mal ein find auf die unit ( find ./ -name "ptc.*" -print) Grüsse, René
Hallo!
Leider habe ich immer noch Probleme FreePascal
auf dem Raspberry ans laufen zu kriegen.
FP von der Konsole gestartet, kein startx mit
Terminalfenster.
Dieses Programm lässt sich kompilieren und starten:
Program UnitTest;
uses crt;
var c:char;
begin
repeat
writeln('TEST');
delay(1000);
until keypressed;
read(c);
end.
wenn ich jedoch per "uses" eine Unit aus dem
arm-linux Directory hinzufüge, kommt es zu einem
Linker-Fehler. z.B. obiges Programm mit den
Units ptccrt oder ptcgraph. Der Compiler findet
zwar die Dateien, das Linken geht aber schief
(Error while Linking).
Fehlerdatei fp___.err:
/usr/bin/ld: warning: /home/pi/turbo/link.res contains output sections;
did you forget -T?
/usr/bin/ld: cannot find -lXxf86vm
/usr/bin/ld: cannot find -lXxf86dga
Ein weiterer Versuch war das Programm zur
"Hardware abstraction library for the Raspberry Pi"
von Stefan Fischer, bei dem das Testprogramm testrpi.pas
und die dazugehörende Unit rpi_hal.pas im gleichen
Quellverzeichnis lagen und keine weiteren Units
benötigt wurden, lieferte folgende Fehlermeldung:
/usr/bin/ld: warning: /home/pi/turbo/link.res contains output sections;
did you forget-T?
/usr/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In function
`_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/usr/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In function
`_haltproc_eabi':
(.text+0x90): undefined reference to `_init'
Wenn ich jedoch anstelle der FP-IDE den Compiler direkt starte
mit "fpc testrpi",
bekomme ich zwar auch die "-T"-Warnung, aber der Linker
erzeugt eine ausführbare (funktionierende) Datei.(!)
Das zuerst genannte Beispiel liefert aber auch mit
fpc direkt gestartet den gleichen Fehler...
Ich bin ratlos, gibt's wieder einen guten Tipp?
Danke!
Berry
Diese Linker-Fehler kommen zustande, da die entsprechenden "-dev"-Pakete fehlen. Welche das sind, liefert z.B. apt-file: apt-file search libXxf86vm.so (nur gerade unter Ubuntu getestet, dürfte auf dem Raspi aber zum selben Ergebnis führen.) Ergebnis: libxxf86vm-dev Dieses Paket einfach nachinstallieren, und schon sollte es tun. Der Linker bekommt von FPC nur die Namen der externen Libraries ohne Versionsnummer (bzw. exaktem Dateinamen) mit, da die von Distribution zu Distribution unterschiedlich sein können, und die erhält man unter Debian-basierten Systemen mit den Dev-Paketen am Einfachsten. Alternativ könnte man von Hand einen Symlink erstellen von libXxf86vm.so auf z.B. libXxf86vm.so.1.0.0, aber das händische Herumgefummle in System-Verzeichnissen....
Danke Sebi, das hört sich leider etwas kompliziert an. Ich hatte gehofft, nach der Installationsanweisung sudo apt-get update sudo apt-get upgrade sudo apt-get install fpc sudo apt-get install lazarus eine vollständige Installation zu bekommen. Schön wäre ein komplettes Paket FreePascal (und Lazarus) mit dem passenden Linux als Image für die SD-Karte. So daß man den Raspi auch offline nutzen kann und nicht immer nach fehlenden Paketen suchen muß. Bei der fehlenden libXxf86vm hätte ich nicht vermutet, daß es eine Lib für den ARM ist. Ich gebe meine Versuche vorerst auf. Viele Grüße Berry
Huhu, naja, Free Pascal selbst ist ja vollständig installiert, aber wenn Abhängigkeiten zu externen Bibliotheken ins Spiel kommen... :) Das Problem ist, die FPC-Pakete können schlecht zu allem, was Schnittstellen-Units an externen Bibliotheken brauchen können, als Abhängigkeit fordern. Nimm mal die ganzen Datenbanken beispielsweise... Und da FPC selbst kein X braucht, werden diese Pakete auch nicht mit reingezogen. (Lazarus bzw. die LCL tuen das dann aber, IIRC) Gruß, Sebi
Hallo Sebastian, wie kann ich schon zu Anfang erkennen, welche Pakete benötigt werden (ohne auf irgendwelche Fehlermeldungen zu warten..)? Wenn nur die Grundfunktionen / Units des alten TurboPascal 6 od. 7 zur Verfügung stehen würden wäre es für mich ausreichend. Und warum noch diese Unterschiede, Fehlfunktion beim compilieren unter FP und Erfolg beim direkten compilieren mit FPC? Die benötigten Libs sollten doch in beiden Fällen die gleichen sein? Viele Grüße Berry
Berry schrieb: > Hallo Sebastian, Hiho, sorry war etwas busy... > wie kann ich schon zu Anfang erkennen, welche > Pakete benötigt werden (ohne auf irgendwelche > Fehlermeldungen zu warten..)? Tja, schwierig. Eine einfache Lösung ist mir auch nicht bekannt. Im Quelltext erkennt man Verweise anhand der "{$linklib xy}"-Direktiven. In welchem Paket dann eine Library steckt, ist wiederum aber Sache der Distribution. Ich verstehe das Gemeckere auch, und ich bilde mir ein, dass es im FPC-Team vor Jahren schonmal eine Diskussion um das Thema gab: Aber, für C/C++-Anwendungen gelten genau dieselben Anforderungen. Es sind ja eben auch alles echte Compiler, daher gelten unter Linux eben auch dieselben Voraussetzungen wie mit einem C-Compiler. > Wenn nur die Grundfunktionen / Units des alten > TurboPascal 6 od. 7 zur Verfügung stehen würden > wäre es für mich ausreichend. Das sollten sie aber doch. Die CRT-Unit jedenfalls; die Graph-Unit ist so eine Sache... wer die freiwillig verwenden will. > Und warum noch diese Unterschiede, Fehlfunktion > beim compilieren unter FP und Erfolg beim > direkten compilieren mit FPC? Die benötigten > Libs sollten doch in beiden Fällen die gleichen sein? Sollte man eigentlich meinen; die FP-IDE setzt aber anscheinend die Pfade etwas anders. Ich verwende die nie, aber... Dort mal gucken, was so voreingestellt ist; Pfade für den Commandline-FPC kann man dann ja leicht in /etc/fpc.cfg (oder die lokale Config) ergänzen. Viel Erfolg, Sebastian
Hallo Sebastian, auch ich habe ein paar Tage aussetzen müssen und kann erst am Wochenende weiterbasteln - sofern das Wetter es zulässt :-) Mit dem Raspberry hatte ich meinen ersten Kontakt zu Linux. Da mir Turbo-Pascal unter DOS bekannt war, hatte ich mit Free Pascal auf einen schnellen Erfolg gehofft. Die Installation von Programmpaketen macht mir aber Sorgen. Nur online per apt-get zu installieren ist mir nicht recht. Ich würde mir die Pakete gerne zurücklegen können für spätere Nachinstallationen. Da muß man sich aber einen Rattenschwanz an einzelnen Dateien (depends on ... depends on ...) downloaden. Aber wahrscheinlich sehe ich das alles zu kompliziert und es gibt doch eine elegante Methode. Noch einmal Vielen Dank und ein schönes Wochenende Berry
Einfach die .deb Dateien aus /var/cache/apt/archives/ sichern und wieder zurückspielen. Ist die einfachste Lösung.. ansonsten würde sich noch apt-proxy oder gleich ein eigenes apt-Repository anbieten
Ok, bin nur mal kurz dürber geflogen, also nicht sauer sein, wenn schon jemand die bemerkung gemacht hat. die units müssten ja schon beim übersetzten des free pascal mit übersetzt werden. ist denn sichergestellt das es uints kompiliert für den ARM auf dem Raspberry Pi (B) gibt? Die müssten dann installiert werden. Da sie ausführbaren code enthalten, würden hier bibliotheken kompiliert für x86 nicht funktionieren. eventeull werden die units nicht installiert, weil es keine für arm kompilierten gibt? aber das ist jetzt nur eine vermutung.
Hallo zusammen! Nach dem Tipp von Sebastian habe die fehlenden Libs installiert: sudo apt-get update sudo apt-get install libxxf86vm-dev sudo apt-get install libxxf86dga-dev daraufhin konnte ich unter fp fehlerfrei kompilieren (FREU!) Leider kommt, wenn ich mein Programm anschliessend starten will unter fp (RUN) : "Permission denied" bzw. beim Starten ausserhalb der FP-IDE "Keine Berechtigung". Ich habe mich schon ganz mutig als root eingeloggt (sudo -i), trotzdem keine Berechtigung... Noch eine andere Frage: Ich versuche gerade vom Netbook auf den Pi zuzugreifen. Mit PuTTY-Portable kann ich mich einloggen (SSH), bekomme aber bei fp (und mc) nicht den Linegrafikfont dargestellt. Kann nicht die richtige Einstellung (Windows / Translation) bei PuTTY finden. Danke für jede Hilfe! Berry
Hallo René, ich hatte schon mit sudo chmod 777 tstgraph die Attribute geändert (leider in der Mail zuvor nicht erwähnt). pi@RASPI01 ~/turbo $ ls -la tstgraph -rwxrwxrwx 1 root root 712144 Jul 26 10:50 tstgraph Das zweite Problem, die Darstellung unter PuTTY, ist gelöst: UTF-8 und Poor man's line drawing... Danke! Berry
Hmmm... Dann ziehst du im Programm evtl. eine File an oder versuchst zu schreiben? Wie sieht die ganze Fehlermeldung aus wenn Du aus der Shell startest? Sonst mal debuggen. Grüsse, René
Es liegt wohl nicht an den Dateirechten des Programms, sondern daran, daß das Programm zur Laufzeit versucht auf die Grafik zuzugreifen. Wenn ich alle Grafikbefehle auskommentiere kann ich das Programm starten. Ich möchte einfache grafische Darstellungen ohne XWindows-Oberfläche, das sollte doch mit der Unit ptcgraph möglich sein? Sonst würde ich Lazarus nehmen. Ich werde 'mal weitersuchen. Vielen Dank an Alle und ein schönes Wochenende! Berry
Hallo Berry, Ok als Linux-Beginner ist das natürlich noch etwas härter, so alles auf einmal... Also das Meiste scheint sich in der Zwischenzeit ja bereits erledigt zu haben. Das mit den Paketen kann man auch mit einem lokalem apt-Mirror (gespiegeltem Paket-Archiv) lösen, Anleitung z.B. hier: http://wiki.ubuntuusers.de/apt-mirror Braucht aber natürlich "etwas" Speicherplatz. Mittlerweile habe ich mich mal kurz über PTC informiert... Ahso, das funktioniert unter Linux nur über X11, also mit X-Server. Blöde Frage, wenn der X-Server eh nicht läuft oder nicht laufen soll sondern nur die Konsole, wäre dann der Zugriff direkt (Graph-Unit) oder über SDL (sdlgraph) nicht schlauer? Ich hatte auch mal vor Ewigkeiten eine GGI-Version beigesteuert, und die scheint immer noch Bestandteil von Linux-FPC zu sein, aber fragt mich jetzt bitte keiner, ob die heutzutage noch funktioniert ;) Das Ding wäre wahrscheinlich am Schnellsten, von der Performance her, aber ich glaube GGI ist ein wenig tot. (Mein Port stammt von 1999...) Zu Lazarus: Läuft das überhaupt auf dem Raspi? Bzw. vernünftig? (Ich habe nur einen der 1. Serie mit 256 MB, da habe ich es erst gar nie versucht...) Ansonsten, mit Lazarus auf dem Desktop entwickeln und Testen ginge natürlich auch, wenn es nicht zu Hardware-spezifisch ist... Gruß, Sebastian
Hallo Sebastian, die "X-xe" in den Dateinamen der Libs liessen es schon befürchten, daß X-Windows vorausgesetzt wird. In den Quellen der ptc-Units ist es auch angegeben. Eine graph-Unit gibt es für die ARM- Version von fpc leider nicht, nur ptcgraph... Lazarus läuft auf dem Raspberry Pi, aber leider ist die Entwicklungsumgebung etwas träge. Schöner wäre Lazarus auf dem PC als Cross-Compiler, so wie es auch bei Windows-CE Anwendungen möglich ist. Ich werde mich mal nach SDL-Graph umsehen, ob es eine ARM-Portierung gibt. Schade, ich hatte mir so sehr ein Turbo-Pascal für den Pi gewünscht. Aber es ist wohl konsequenter mit Lazarus zu arbeiten, bietet es doch für grafische Anwendungen eine viel bequemere Entwicklungsumgebung. Vielen Dank für Deine Hilfe, Berry
Hallo Berry, die SDL-Pakete dürfte es relativ sicher auch für ARM geben, und die FPC-Units sind sowieso ziemlich Prozessor-unabhängig, die SDL-Graph müsste also laufen. SDL hat den Vorteil, dass es sowohl mit als auch ohne X11 laufen kann. Also z.B. Testen auf dem Desktop mit SDL-X11, und dann fertiges Programm auf dem Raspi mit SDL direkt auf Framebuffer. Oder eben nur auf dem Rasi entwickeln, wie und mit was ist Geschmackssache. (...mir persönlich reicht für kleinere Sachen meist der Editor des Midnight Commanders. Komfort ist aber natürlich etwas anderes.) Das mit dem Cross-Compilen... Von Unix-Systemen (Linux, OS X...) nach Windows kein Problem, Windows auf Windows Mobile auch nicht, aber nicht Windows nach *nix... FPC muss wissen, für welche Version der libc er ein Programm erstellen muss, und spätestens der Linker würde aus genau denselben Gründen, warum man die -dev-Pakete benötigt, versagen. Meines Wissens nach ist es daher nicht möglich, von Windows aus für irgendein Linux (egal ob x86 oder ARM) zu cross-compilen, eben weil der Linker so nicht funktionieren kann. Umgekehrt geht es halt deshalb problemlos, weil Windows-Executables in ihrer Funktions-Import-Liste nur die einfachen Namen der benötigten DLLs benötigen. Bei WinCE/Mobile dasselbe. Soll heißen, ob die DLLs überhaupt vorhanden sind, ist dem Linker egal. Grüße, Sebastian
Hallo Sebastian, die SDL-Lib zu verwenden ist ein guter Rat. In der Zwischenzeit habe ich testweise den BASIC-Interpreter RTB (Return To Basic) http://projects.drogon.net/return-to-basic/ installiert. Dieser verwendet auch die SDL und liefert problemlos Grafiken ohne dass LXDE gestartet sein muß. Kann auch die GPIO ansprechen und über einen USB-Adapter seriell kommunizieren - all das, was mir mit Free Pascal nicht gelingt. Ein Testprogramm mit den eingebundenen Units SDL und CRT wird fehlerfrei kompiliert, jedoch wird das Ausführen des Programms mit "Keine Berechtigung" verhindert. Ich habe die Datei mit chmod 777 für alles freigegeben, mit sudo und als root gestartet, immer das Gleiche. Da RTB die Berechtigung hat Grafiken darzustellen, habe ich mein Programm mit den gleichen Rechten versehen (oktal) 104755, Eigentümer: root, Gruppe: root und ins gleiche Verzeichnis verschoben: /usr/local/bin - leider auch ohne Erfolg. Viele Grüße Berry
Hallo Berry, dazu fällt mir leider auch nicht viel ein; ich werde mal morgen oder die Tage versuchen, das selbst nachzuvollziehen. (...kann im Moment wg. Baustelle nicht viel garantieren ;) ). Eventuell hilft ein Start über strace, also mit "strace <programmname>", damit sieht man oft ganz gut, warum und weshalb ein Programm schon bei der Initialisierung scheitert. Schaun mer mal... Gruß, Sebastian
Danke Sebastian, inzwischen bin ich ein wenig weitergekommen. Da ich den Raspberry nicht dabeihatte, habe ich mit QEMU ein Minimal-Image (ohne XWindows) geladen und FPC mit SDL installiert. Jetzt schaltet das Programm in den Grafikmodus um! Es gibt noch Probleme beim zurückschalten, scheint beim Beispielprogramm an einem dispose zu liegen, aber dieses Problem lässt sich lösen. Eine für mich wichtige Frage zum SDL-Paket hätte ich noch: gibt es dort auch einfache Zeichenroutinen in der Art setpixel(x,y) drawline, drawcircle ...? Ich habe dafür noch keine Prozeduren gefunden. Viele Grüße Berry
Berry schrieb: > Danke Sebastian, > > inzwischen bin ich ein wenig weitergekommen. > Da ich den Raspberry nicht dabeihatte, habe > ich mit QEMU ein Minimal-Image (ohne XWindows) > geladen und FPC mit SDL installiert. Hm das hätte ich auch gemacht, wenn ich den Raspi nicht gerade zum Spielen frei hätte ...ich halte ihn aber mal ein paar Tage bereit, irgendwas stimmt doch da nicht ;) > Eine für mich wichtige Frage zum SDL-Paket > hätte ich noch: gibt es dort auch einfache > Zeichenroutinen in der Art setpixel(x,y) > drawline, drawcircle ...? Ich habe dafür noch > keine Prozeduren gefunden. Ja gibt es, über die Unit sdl_gfx. (Achtung, braucht anscheinend das Paket libsdl-gfx1.2-dev...) Linien, Kreise, Ellipse, Tortenstücke, Dreiecke, Polygone, Bezier-Kurven, Text (aber wie? Muss man wohl in der SDL-Doku schauen), diverse Bitmap-Effekte. Oder einfach mal die SDLGraph-Unit ausprobieren? Unit Graph über SDL? sdl_gfx ist allerdings mit Sicherheit schneller und eher leistungsfähiger. Was übrigens auch ginge: Die (mehr oder minder) Delphi-kompatiblen Grafik-Klassen nehmen und damit ein Bild 'offscreen' aufbauen und dieses am Schluss per SDL auf den Bildschirm bringen. Der Vorteil wäre, dass der eigentliche Grafikcode auch mit Lazarus unter X11/Windows/etc. ohne Änderungen funktionsfähig wäre. Aber ohne Beispiel zum Starten ist das natürlich eine fade Angelegenheit... Viele Grüße, Sebastian
Juhuuh, ein Kreis! (Inzwischen schon etwas mehr als das...) "libsdl-gfx1.2-dev" war die Lösung! Soweit, so schön. Es klappt. Vielen Dank für alle hilfreichen Tipps. Noch läuft es auf dem Simulator (QEMU), aber mit dem Image auf SD-Karte kopiert sollte auch der "echte" Raspberry damit klarkommen. Wenn mir noch eine Frage erlaubt ist: Kann ich bei der Textausgabe verschiedene Fonts auswählen? In der SDL_GFX-Beschreibung zur originalen C-Version gibt es "SET_FONT". Dies scheint in der FPC-Version nicht vorhanden zu sein. Die Alternative, mit SDL_TTF zu arbeiten, ergibt beim Einbinden der Unit wieder einen Linker-Fehler: "/usr/bin/ld: cannot find -lSDL_ttf" Da fehlt wohl wieder eine Library. Ins Blaue hinein hab ich versucht die "libsdl-ttf1.2-dev" zu installieren, aber die gibt es leider nicht... Viele Grüße! Berry
Berry schrieb: > Juhuuh, ein Kreis! > > (Inzwischen schon etwas mehr als das...) > "libsdl-gfx1.2-dev" war die Lösung! > Soweit, so schön. Es klappt. Super! > Wenn mir noch eine Frage erlaubt ist: > Kann ich bei der Textausgabe verschiedene > Fonts auswählen? In der SDL_GFX-Beschreibung > zur originalen C-Version gibt es "SET_FONT". > Dies scheint in der FPC-Version nicht > vorhanden zu sein. Ich vermute mal, das wird diese hier sein (in sdl_gfx.pas): procedure gfxPrimitivesSetFont(const fontdata: Pointer; cw: integer; ch: integer); cw und ch klingt nach "character widht" und "height". > Die Alternative, mit SDL_TTF zu arbeiten, > ergibt beim Einbinden der Unit wieder einen > Linker-Fehler: > "/usr/bin/ld: cannot find -lSDL_ttf" > Da fehlt wohl wieder eine Library. > Ins Blaue hinein hab ich versucht die > "libsdl-ttf1.2-dev" zu installieren, aber > die gibt es leider nicht... Ja, aber folgender Tipp: In sdl_ttf.pas, verschachtelt in ein paar Plattform-Abfrage-IFDEFs versteckt, findet man unterhalb der Definition SDLttfLibName = 'libSDL_ttf.so'; noch eine Nicht-FPC-Definition (für was dann? GNU Pascal?) SDLttfLibName = 'libSDL_ttf-2.0.so.0'; Und in der Tat gibt es das Paket libsdl-ttf2.0-dev... :) Viele Grüße, Sebastian
Grrrrr.... Für meine Versuche mit dem Raspberry-Simulator QEMU hatte ich das "84 MB Minimal Raspbian ARMHF Image for Raspberry Pi" vewendet. http://www.cnx-software.com/2012/07/31/84-mb-minimal-raspbian-armhf-image-for-raspberry-pi/ Nach den länderspezifischen Anpassungen habe ich den mc installiert sowie FreePascal und (nach Hilfestellung) die fehlenden SDL-Libs. Unter QEMU konnte ich die SDL-Programme kompilieren und starten. Dieses, unter QEMU erweiterte Image (meine Arbeitsplattform) habe ich jetzt auf eine SD-Karte kopiert und im Raspberry gestartet. Alles prima, wie unter dem Simulator kann ich meine Programme starten. Mein bisheriges SD-Image (das offizielle Wheezy) habe ich mit FPC und den gleichen Libs installiert. Sobald ich aber die SDL-Unit einbinde (auch ohne Verwendung irgendwelcher SDL-Routinen, nur "uses SDL"), kommt beim Programmstart die Meldung "keine Berechtigung"... Ich würde mit dem Image der Minimalversion weiterarbeiten, nur dort habe ich keinen Zugriff auf den USB-Speicherstick. Dieser wird beim booten zwar erkannt, taucht aber im mc nicht auf. Bei dem großen Image kann ich über den Dateimanager von LXDE auf den Stick zugreifen. Ich geh' mir jetzt erstmal ein neues Beißholz besorgen. Viele Grüße, Berry
Berry schrieb: > > Mein bisheriges SD-Image (das offizielle Wheezy) habe ich mit > FPC und den gleichen Libs installiert. > Sobald ich aber die SDL-Unit einbinde (auch ohne Verwendung > irgendwelcher SDL-Routinen, nur "uses SDL"), kommt beim Programmstart > die Meldung "keine Berechtigung"... Kann gerade nur kurz antworten... strace mal ausprobiert? Ansonsten weiß ich nicht auswendig, ob das Image den Zugriff irgendwie beschränken könnte, mit SELinux oder was weiß ich... > Ich würde mit dem Image der Minimalversion weiterarbeiten, nur dort > habe ich keinen Zugriff auf den USB-Speicherstick. Dieser wird beim > booten zwar erkannt, taucht aber im mc nicht auf. > Bei dem großen Image kann ich über den Dateimanager von LXDE auf > den Stick zugreifen. Kann man den Stick nicht mit "mount /dev/sda1 /mnt" (oder /dev/sdb1...) von Hand einbinden? > Ich geh' mir jetzt erstmal ein neues Beißholz besorgen. Au ja. Ich plane derweil weiter, wie ich gegen die Hitze vorgehen soll ;) Gruß, Sebastian
Hallo Sebastian!
"mount /dev/sda1 /mnt" so einfach? Tatsächlich, es funktioniert!
Ich hatte mir den mount-Befehl schon angesehen, aber aufgrund der dort
aufgeführten vielen Parameter gid, uid, umask, -t -o ... lieber Abstand
genommen.
strace mit -o in eine Datei umgeleitet liefert:
execve("./sdl002", ["./sdl002"], [/* 18 vars */]) = -1 EACCES
(Permission denied)
dup(2) = 3
fcntl64(3, F_GETFL) = 0x20002 (flags
O_RDWR|O_LARGEFILE)
fstat64(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb6fd5000
_llseek(3, 0, 0xbefa6360, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: Permission denied\n", 32) = 32
close(3) = 0
munmap(0xb6fd5000, 4096) = 0
exit_group(1) = ?
Ich glaube, dieses SD-Card-Image hat eine Macke. Vielleicht ist bei
einer
Installation mal etwas schiefgelaufen.
Vielen Dank für die Unterstützung
und ein schönes Wochenende!
Berry
Berry schrieb: > Hallo Sebastian! > > "mount /dev/sda1 /mnt" so einfach? Tatsächlich, es funktioniert! Fein :) > Ich hatte mir den mount-Befehl schon angesehen, aber aufgrund der dort > aufgeführten vielen Parameter gid, uid, umask, -t -o ... lieber Abstand > genommen. Jaja, das ganze Finetunging und die Rechteverwaltung... braucht's in dem Fall ja alles nicht. Spätestens bei mehreren Usern kann es kniffliger werden. > strace mit -o in eine Datei umgeleitet liefert: > > execve("./sdl002", ["./sdl002"], [/* 18 vars */]) = -1 EACCES > (Permission denied) Gut, hier steigt er ja irgendwie schon aus, direkt am Anfang. Hm, die möglichen Ursachen anscheinend: - im Pfad (mal "echo $PATH" probiert?) steht etwas Ungültig drin - Datei ist keine normale Datei oder X-Recht fehlt - Datei liegt auf einem Dateisystem, auf welchem keine Dateien ausgeführt werden können. Kommt bei "mount" ein NOEXEC in der Liste vor? > Ich glaube, dieses SD-Card-Image hat eine Macke. Vielleicht ist bei > einer Installation mal etwas schiefgelaufen. Puh, möglich ist Vieles, mal eine andere SD-Card probiert? Der Raspi mag nicht alle. Grüße, Sebastian
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.