MitjaStachowiak hat geschrieben:Ich hoffe, dass die Typen für size_t so stimmen. Das readlink geht auf meinem x86 auf jeden Fall. Das ganze soll dann später auf einem ARM-Soc laufen.
MSEgui hat die Units msectypes und mselibc worin diese Typen für die Linux und FreeBSD Versionen definiert sind.
https://gitlab.com/mseide-msegui/mseide ... ctypes.pashttps://gitlab.com/mseide-msegui/mseide ... selibc.pasAuch Free Pascal hat eine ctypes-Unit.
Aktuell hänge ich daran, das mit dem Crosscompiler zu linken. Habe FPC als Crosscompiler Linux i386 -> Linux arm eingerichtet. Kann das Programm ohne die Syscalls auch für ARM kompilieren. Mit kommt wieder ein Linker Error. Heißt dass ich muss eine "cross-glibc" für ARM nachinstallieren, damit der Linker das findet?
Ja. Es müssen auch Links lib*.so -> lib*.so.n vorhanden sein, siehe den ewigen Bugreport
https://bugs.freepascal.org/view.php?id=32367erste Diskussionen über das Thema liegen 10 Jahre zurück.
Vollständige Cross-Compiling-Debugging Umgebungen Linux -> ARM (Raspberry Pi) sind hier:
https://sourceforge.net/projects/mseide ... pcrossarm/Für MSEide gibt es auch ein entsprechendes Projekttemplate, siehe MSEide+MSEgui README.TXT.
Du könntest zuerst mit RPi üben und dich mit dem SOC herumschlagen, sobald es auf dem RPi grundsätzlich funktioniert.
Für Embedded gibt es auch eine entsprechende Version:
https://sourceforge.net/projects/mseide ... membedded/Siehe auch
viewtopic.php?p=102817#p102817Oder gibt es die Möglichkeit, das dynamisch zu machen? Auf Windows muss eine verwendete DLL ja auch nicht installiert sein, damit man es zumindest kompilieren kann.
Man könnte GetProcAddress() verwenden statt "statically shared" zu linken. Entsprechende Routinen sind hier:
https://gitlab.com/mseide-msegui/mseide ... ynload.pasAFAIK braucht der Linux Linker für "statically shared" Zugriff auf die Bibliothek zur Kompilierzeit unter anderem um den SONAME zu bestimmen.