BGRAControls Install per OPM : Compiler PANIC!

[att2]

Mein system: Eine Virtualbox-VM mit Linux Mint 19/Tara+updates, LAZ 2.1.0 "trunk version", FPC 3.3.1beta "trunk version" , installiert dank FPCUPDeluxe 1.8.6d.

Ein Versuch, die BGRAControls via Online-Package-Manager zu installieren, gibt mir folgenden compiler error :
-----------------------------------------------------------------------------------------
Kompiliere Package bgracontrols 6.6.1: Access violation
$0000000000536ACD
$0000000000536CCE
$00000000009C6560 EXECUTE, line 1603 of exttools.pas
, Fehler: 4, Warnungen: 6, Hinweise: 2
bctools.pas(281,3) Warning: Case statement does not handle all possible cases
bctools.pas(581,14) Hint: Local variable "p" of a managed type does not seem to be initialized
bctools.pas(670,3) Warning: Case statement does not handle all possible cases
bceffect.pas(184,3) Warning: Case statement does not handle all possible cases
bceffect.pas(224,3) Warning: Case statement does not handle all possible cases
bcfilters.pas(320,21) Hint: Local variable "gpallete" of a managed type does not seem to be initialized
bcfilters.pas(797,3) Warning: Case statement does not handle all possible cases
Warning: Recompiling BGRASliceScaling, checksum changed for /home/arm2/programme/lazarus/config_lazarus/onlinepackagemanager/packages/bgrabitmap-master/bgrabitmap/lib/x86_64-linux/3.3.1/bgrabitmap.ppu
Panic: interner Fehler: Access violation
Panic: interner Fehler: $0000000000536ACD
Panic: interner Fehler: $0000000000536CCE
Panic: interner Fehler: $00000000009C6560 EXECUTE, line 1603 of exttools.pas

-----------

Was soll ich tun? Wie installiere ich BGRAControls? Es plagt mich schon tagelang, bin schon verzweifelt....

[wennerer]

Hallo,
hast du es schon mal mit fpcupdeluxe probiert (unter Modules). Ich konnte es so ohne Probleme installieren.

Gruß Bernd

[af0815]

Kann auch daher rühren, das es im fpc trunk manchmal zu Änderungen kommt, mit denen andere fpc-fremde Pakete sich nicht compilieren lassen. Kann auch sein, das das Paket im OPM nicht den Änderungen im trunk folgen kann. Ev. mit dem Paket der originalquelle versuchen.

[Mathias]

Hallo,
hast du es schon mal mit fpcupdeluxe probiert (unter Modules). Ich konnte es so ohne Probleme installieren.

Gruß Bernd

Momentan hat fpcupdeluxe mit allen aktuellen Lazaren Probleme, nur fpc geht.

[wennerer]

Hallo,
war mal Neugierig und hab es mit meiner Version in Virtualbox probiert. Meine Daten:

Linux Mint 19.3 Cinnamon Version 4.4.8 (in der Virtualbox)

Lazarus 2.1.0
Datum 2020-01-30
FPC-Version 3.3.1
SVN-Revision 62599M

FPCUPdeluxe V1.6.8a for x86_64-linux-gtk2

Konnte die BGRAControls ohne Probleme installieren. Vielleicht war es ja nur Glück
Aber es Lohnt sich zu probieren.
Viele Grüße Bernd

[Warf]

Eine PANIC ist kein kompilierfehler im klassischen Sinn, sondern ein Bug im FPC. Da du die FPC Trunk beta verwendest also auch nicht verwunderlich, da musst du mit rechnen das die nicht stabil ist. Du kannst 2 sachen versuchen: 1. FPC updaten, vielleicht wurde das schon gefixt, 2. FPC downgraden, also mit SVN eine ältere Revision auschecken bei der der Bug noch nicht drin war.
Bugs sind von Natur aus auch meistens nicht so trivial, kann also gut sein das der Bug nicht nur wegen dem BGRAControls code fehlschlägt, sondern wegen dem zusammspiel der speziellen OPM version, der BGRAControls version, beiner Betriebsystem version und anderen Komponenten die du bereits installiert hast.
Falls es dazu noch kein Bugtracker Ticket gibt und das in der neusten Trunk version noch nicht gefixt ist (und du den Fehler reproduzierbar isolieren kannst), solltest du natürlich auch ein solche aufmachen

Persönlich benutze ich einfach eine stabile FPC version, da muss man sich mit sowas nicht rumplagen

[Mathias]

Vielleicht, liegt es an meinem PC, da nicht mal mehr die stable geht.

[att2]

Ihr seht also, wie mir es immer geht mit dem Lazarus/FPC: Im "Prinzip" eine Super-Software, ja die beste der Welt für den Zweck oder so
In der Praxis : Ein Bug nach dem anderen. Ein Install-Problem nach dem anderen. Eine Library-Hell nach der anderen. Und Cross-Compilieren ist noch ärgerlicher.
Ich hätte da einen kleinen Vorschlag/Auftrag :

Kann jemand von euch eine Linux-Mint-VM irgendwo, z.B. auf Google Drive, uploaden, die folgendes enthält :
Neuester Lazarus, der geht ; neuester FPC, der geht ; einwandfreies Cross-Compile ohne Libraryhell und ohne Linkerprobleme nach Win32, Win64, Intel/Linux32,64, ARM, und AARCH64 ?

MUSS ausserdem noch folgende Packages FÜR ALLE WIN,LIN,ARM enthalten und einwandfrei cross-compilen :
BGRABitmap, BGRAControls, LazSerial, Playsoundpackage, TDINotebook, TAChartAgg/BGRA/, LazarusPkg/Print,
TDI, ToDoListLaz, Printer4Lazarus, oxml_lazarus, LazOpenGLContext, FPVectorialPkg; Online-Packagemanager; Anchordockingdesign.

Bonus: SOLL LCL-QT, QT5 einwandfrei cross-compilen (ARM, WIN32+64) können, weil alle cross-compile-libs vorhanden sind. Als normaler User.

Gibt's nicht sowas fixfertig oder könnte das jemand uploaden und anbieten bitte ?

Ich habe wirklich keine Lust, und ich übertreibe es hier nicht sondern meine es genau so, wie geschrieben : mich WOCHENLANG mit Libraries und missing cross compile errors abzuplagen, bis ich zum ersten Mal etwas einwandfrei compilieren kann..... wochenlang!

[Warf]

Gibt's nicht sowas fixfertig oder könnte das jemand uploaden und anbieten bitte ?

Ich habe wirklich keine Lust, und ich übertreibe es hier nicht sondern meine es genau so, wie geschrieben : mich WOCHENLANG mit Libraries und missing cross compile errors abzuplagen, bis ich zum ersten Mal etwas einwandfrei compilieren kann..... wochenlang!

Ich denke kaum jemand hat zufällig für jede mögliche Kombination an Packages eine VM rumfliegen. Wobei natürlich ein entsprechender Docker-Container für Cross-Compiling sich mehr anbieten würde (es gibt sogar zwei lazarus-cross compiler docker images, ob die laufen keine Ahnung).

Aber mal ne ganz dumme Frage, wenn cross compilen so beschissen ist, warum machst du das überhaupt? Ich kompilier meine Programme für Windows und Linux, bin aber nicht so blöd und mach mir den Aufwand einen Cross-Compiler einzurichten. Sowohl unter Linux als auch unter Windows kannst du ganz einfach VMs benutzen, unter Linux kannst du mit Wine und unter Windows mit dem WSL auch ganz einfach lazarus (bzw lazbuild) für das entsprechend andere System ausführen, ohne das du eine VM brauchst.
Mit docker unter Linux wirst du auch das 32 und 64 bit Problem los (das du bei Windows ja nicht hast), und mit QEMU kannst du sogar ganz einfach ein ARM Ubuntu image booten in dem du dann Lazarus installieren kannst.

Ich hab Cross-Compiling schon lang aufgegeben, weil es schlicht weg einfacher ist das ganze Problem zu umgehen. Ne Linux oder Windows VM aufzusetzen dauert maximal 20 minuten

Zu den Packages und bugs, ich hoffe dir ist klar das wenn du FPC und Lazarus Trunk verwendest du auf der aktiven Entwicklungsversion der beiden Programme arbeitest, du kannst also nicht erwarten das es bug frei ist. Wenn du was stabiles haben willst benutz ne stable version und keine bleeding edge trunk version. Es kommt zwar nicht so sehr oft vor, aber wenn du trunk benutzt kann es halt mal sein das für ein paar tage oder ne woche, oder vielleicht sogar länger bugs drin sind. Ich hab bereits schon vor ein paar jahren angefangen für jedes relevante Projekt nur noch die aktuelle stable version zu benutzen (und die auch meist im projekt nicht zu updaten), einfach weil ich schon ein paar mal in das problem gelaufen bin das ein temporärer bug die entwicklung von meinem projekt für ne woche oder mehr still gelegt hat. Außerdem kann es passieren das einfach von heut auf morgen eine komplette Unit umgestellt wird und wenns noch besser kommt die ein paar Tage später wieder geändert wird, sodass man mehrfach 2 man einen kompletten Tag oder mehr zum fixen von inkompatibilitäten aufwenden muss.
Zugegeben das kommt alles nicht sehr häufig vor (ich hab auch immer ne trunk version installiert um neue features etc zu testen), aber wenn es vorkommt ist es halt in einem großen projekt extrem beschissen.

Noch dazu kommt das die Package Entwickler selbst ja auch genug zu tun haben um sich nur um die Aktuellste stable version von ihren packages zu kümmern. So ein BGRAControls wird vielleicht von einigen Entwicklern auf Trunk entwickelt, aber am Ende des Tages ist das ziel das es auf Stable läuft, da zum einen die meisten Entwickler Stable benutzen, und zum anderen sich Trunk so schnell ändern kann, das man als Package entwickler keine Garantien geben kann. Wenn also packages auf trunk nicht laufen, musst du im Hinterkopf behalten das sie wahrscheinlich nie für Trunk (und erst recht nicht für die neuste Revision die vielleicht erst nach dem letzten Update des Packages rauskam) gebaut oder getestet wurde.

Langer Rede kurzer Sinn: Wenn du ein stabiles system haben willst, benutz nicht Trunk, oder wenn du Trunk benutzen willst, beschwer dich nicht das es nicht stabil läuft. Trunk ist bleeding edge, nicht stable.

Das ist das selbe mit z.b. Linux Mint vs Arch, wenn man Mint benutzt kann man ein sehr stabiles system erwarten, muss aber in kauf nehmen nicht die neuste Software zu haben. Bei Arch hat man immer die neuste software, dafür kann es vorkommen das nach einem Update dein System nicht mehr bootet. So ist das auch mit dem FPC, wenn du trunk benutzt hast du zwar die ganz neuen features, darfst dich aber nicht wundern wenn der panict.

Ansonsten kann ich nur meine Aussage vom Anfang widerholen, cross compilen ist nunmal scheiße, lässt sich aber ganz einfach umgehen. Und mit der stable version von Lazarus und FPC hatte ich nie Probleme mit Packages, zumindest nie welche die ich nicht lösen konnte (im schlimmsten Fall musste ich einen typen in einer zeile fixen, oder bei Indy in einer bestimmten reihenfolge kompilieren, aber nix was nicht nach ein paar stunden gelaufen wäre). Wobei das nicht ganz stimmt, manchmal trifft man auch auf packages die seit 10 jahren oder so kein Update mehr bekommen haben, da ists aber nicht verwunderlich das die nicht mehr laufen, und da sollte man sich eh fragen ob man die wirklich benutzen will. Die packages die du willst sollten aber eiegentlich problemlos auf nem Stable Lazarus laufen

[af0815]

Es gibt nur einen FPC der geht -> stable
Lazarus der geht -> stable

Alles andere kann bei den vielen Komponenten und Plattformen zwicken. Und ist auch klar kommuniziert -> Benutze trunk auf eigene Gefahr. Eine gewisse Alternative sind die fixes Zweige. Denn das sind die kommenden Stable Zweige.
Vor allen, bleib am Boden mit den Wünschen.

[att2]

Gibt's nicht sowas fixfertig oder könnte das jemand uploaden und anbieten bitte ?

Ich habe wirklich keine Lust, und ich übertreibe es hier nicht sondern meine es genau so, wie geschrieben : mich WOCHENLANG mit Libraries und missing cross compile errors abzuplagen, bis ich zum ersten Mal etwas einwandfrei compilieren kann..... wochenlang!

Ich denke kaum jemand hat zufällig für jede mögliche Kombination an Packages eine VM rumfliegen. Wobei natürlich ein entsprechender Docker-Container für Cross-Compiling sich mehr anbieten würde (es gibt sogar zwei lazarus-cross compiler docker images, ob die laufen keine Ahnung).

Aber mal ne ganz dumme Frage, wenn cross compilen so beschissen ist, warum machst du das überhaupt?

Na gut, du hast es so gewollt, also erkläre ich es dir: FÜR DIE FIRMA!
Wir produzieren eigene Messgeräte und Stationen im Bereich pharmazeutisches-medizinisches MSR (Messen Steuern Regeln); eines unserer Geräte hat als Steuereinheit nun mal einen Raspi-Clone (aber keinen Raspi), und dort rennt unsere eigene Software drauf.
Wir hatten jede Menge technischer Probleme, aber ich definiere sie nicht als Stolpersteine, sondern als zu überwindbare Hürden, was bei mir bisher so einigermassen klappt.
Beispielsweise brauchen wir 4 serielle highspeed Schnittstellen; von der Hardware her hat der Raspi-Clone diese auch, aber man muss dem Linux-Kernel das erst sozusagen mitteilen, wie es die Hardwareregister zu verwenden hat.
Früher war das mal eine relativ simple Sache von "bin2fex", ini-datei-ähnlichen Text editieren, "fex2bin", zurückkopieren; aber jetzt gibt es schon eine alptraumhaftere Version davon namens "Device Tree Blob".

Gottlob hat uns der Hersteller von dem Raspi-Clone in seinem Forum sehr geholfen, die DTB/DTS-Datei so hinzubiegen, dass uns das Kernel 3.6.18.x auch wirklich die UARTS als serielle Interfaces zur Verfügung steht. Aber das war nur ein paar verschissene Tage, nix besonderes. Echt scheisse war es, den Cross-Compiler hinzukriegen. Ich schreibe mal bewusst einen längeren Beitrag, wie es mir dabei ergangen ist :

Also, wen es interessiert:

Die meisten installieren ihren Laz/FPC auf einen Banana-Pi oder Orange-Pi, etc.
Das haben wir in der Firma auch versucht.
Wir haben mit dem BananaPi angefangen und es brauchte einen ganzen Tag um den Laz/FPC zu installieren, weil, ... die SD-Karte soooooo langsam ist. (Ja auch die "schnelle", "zerifizierte"!)
Dann versuchten wir, unser Projekt zu compilieren. Das sind 16.000 Codezeilen in 43 Dateien, die EXE wird 50-60 MB, je nachdem.
Mein Chef war enttäuscht: "Jedes mal, wenn ich compiliere, kann ich auf einen Kaffee gehen!"
Es war schrecklich langsam.

Innerhalb 5 Tagen ging die originale SD-Karte kaputt da so viele kleine Files so oft beschrieben wurden. Für solch einen Dauerbetrieb sind SD-Karten nun mal nicht gemacht....
Es wurde etwas besser, als wir einen Odroid C2 mit EMMC einsetzen, aber das langsame Kompilieren blieb uns erhalten.

Schliesslich sagte ich dem Boss, es wäre besser, wenn wir eine Linux-Distro zum cross-compilen verwenden könnten.
Zuerst haben wir es auf echter Hardware versucht, aber auch das war ein Fehler (warum? Ist ne zu lange Geschichte, sorry...) also verwenden wir eine VM.
Jedenfalls passieren mir in der VM auch noch mehr Fehler: Ich versuchte, mit Ubuntu loszulegen, aber es gibt viele Ubuntu library Probleme, welche im Lazarus-Forum englisch lang diskutiert werden.
Also probierte ich als nächstes OpenSuse, aber das war auch ein Fehler. Es installierte leicht, aber cross-compilierte nicht.
Schliesslich machte ich das Richtige, indem ich den "FPCUpDeluxe"-Programmierer fragte: "Welche Distro nimmst du? Ich krieg immer Fehler!"
Er sagte mir, ich soll Linux Mint 19 Tara verwenden. Genau das machte ich und hier beginnt die eigentliche Geschichte....

Damals verwendete ich FPCUPDeluxe 1.6.1n aber ich hatte immer noch nicht enden wollende Probleme, ich habe den falschen Compiler verwendet, FPC 3.0.0.
Das führte dazu, dass ich nicht alle Libraries compilieren konnte, auch den Lazarus selber nicht: "bcsvgviewer.pas (228,13) Error: Internal Error 2012090607".
Also selektierte ich "Lazarus stabil, 1.8.4" und "FPC Fixes, 3.2" innerhalb FPCUPDeluxe, und das funktioniert jetzt! ....
.... sagte ich "funktioniert"? , Ja, nach noch weiteren Kämpfen.
Ich musste noch mit den Libraries kämpfen. Einige compilieren nur dann wenn der Lazarus in "debug mode" ist.
Zuerst muss man Lazarus in "Optimized IDE" mode compilieren, dann in "Debug Mode" und NUR DANN compiliert er die notwendigen Libraries!

Einige Lib's holte ich mir direkt als Binary von der Zielmaschine, das "libXtst.so" und kopierte sie ins richtige crosscompile-Verzeichnis. Das war für mich etwas unlogisch.
Einige Lib's funktionieren nur richtig unter Linux/Intel und Windows, aber nicht unter Linux/ARM,aarch64.
Mein Boss, ein wirklich begnadeter und Delphi-Profi, musste die LazSerial library debuggen, damit sie die höheren Geschwindigkeiten vom Odroid C2 auch wirklich verwenden kann.
Er hat das Termios.inc und das lazsynaser.pas file diesbezüglich debugged. Weltklasse!!

Bis das aber soweit war, mussten noch mehr Libraries compiliert werden. Wir verwenden:
BGRABitmap, BGRAControls, LazSerial, Playsoundpackage, TDINotebook, TAChartAgg/BGRA/, LazarusPkg/Print,
TDI, ToDoListLaz, Printer4Lazarus, oxml_lazarus, LazOpenGLContext, FPVectorialPkg.

Alle TAChart' Packages waren trickreich zu installieren, nämlich verlangen sie eine bestimmte Reihenfolge zum Installieren, sonst klappts wieder mal nicht.

Nach WOCHEN solcher Arbeitszeit war es endlich soweit, unsere eigene Software konnte kompiliert werden.
Sie compiliert (16.000 Zeilen code, 43 Dateien) in 7.8 secs auf einen DualXeon X5670 mit 32GB Ram in einer VirtualBox VM.
Quick compile braucht 1.8 secs.

Das ist jetzt schon sehr viel besser als die "+5 mins compilezeit" eines BananaPi.

Mein FPC Verzeichnis ist ca. 3.2 GB ; das neue Laz 2.1.0/FPC 3.3.1 Verzeichnis sogar 4.9 GB.
Noch Fragen? Du kannst ruhig fragen, aber ich will mich eigentlich gar nicht mehr erinnern, was das alles für eine Qual war....

Ich kompilier meine Programme für Windows und Linux, bin aber nicht so blöd und mach mir den Aufwand einen Cross-Compiler einzurichten. Sowohl unter Linux als auch unter Windows kannst du ganz einfach VMs benutzen, unter Linux kannst du mit Wine und unter Windows mit dem WSL auch ganz einfach lazarus (bzw lazbuild) für das entsprechend andere System ausführen, ohne das du eine VM brauchst.
Mit docker unter Linux wirst du auch das 32 und 64 bit Problem los (das du bei Windows ja nicht hast), und mit QEMU kannst du sogar ganz einfach ein ARM Ubuntu image booten in dem du dann Lazarus installieren kannst.

Nun, die Idee mit qemu und ARM-Ubuntu-Image gefällt mir. Aber wie gut das klappt, wird wohl erst die Praxis zeigen.

Ich hab Cross-Compiling schon lang aufgegeben, weil es schlicht weg einfacher ist das ganze Problem zu umgehen. Ne Linux oder Windows VM aufzusetzen dauert maximal 20 minuten

Jaja, die VM. Aufsetzen ist das geringste. Aber cross compile... und du darfst mir glauben, wir brauchen es !

Zu den Packages und bugs, ich hoffe dir ist klar das wenn du FPC und Lazarus Trunk verwendest du auf der aktiven Entwicklungsversion der beiden Programme arbeitest, du kannst also nicht erwarten das es bug frei ist. Wenn du was stabiles haben willst benutz ne stable version und keine bleeding edge trunk version. Es kommt zwar nicht so sehr oft vor, aber wenn du trunk benutzt kann es halt mal sein das für ein paar tage oder ne woche, oder vielleicht sogar länger bugs drin sind. Ich hab bereits schon vor ein paar jahren angefangen für jedes relevante Projekt nur noch die aktuelle stable version zu benutzen (und die auch meist im projekt nicht zu updaten), einfach weil ich schon ein paar mal in das problem gelaufen bin das ein temporärer bug die entwicklung von meinem projekt für ne woche oder mehr still gelegt hat. Außerdem kann es passieren das einfach von heut auf morgen eine komplette Unit umgestellt wird und wenns noch besser kommt die ein paar Tage später wieder geändert wird, sodass man mehrfach 2 man einen kompletten Tag oder mehr zum fixen von inkompatibilitäten aufwenden muss.
Zugegeben das kommt alles nicht sehr häufig vor (ich hab auch immer ne trunk version installiert um neue features etc zu testen), aber wenn es vorkommt ist es halt in einem großen projekt extrem beschissen.

Jaaa ganz genau das merke ich auch im OnlinePackageManager -- da werden bei Packages offenbar mit einem Wahnsinnstempo nachkorrigiert, aber äh.... ich weiss nicht, .... ob das dann auch gut durchdacht ist?
Ich merke es immer wieder, dass eine Package nur "gut geht" im Betriebssystem X mit CPU Y, aber nicht wo anders.

Noch dazu kommt das die Package Entwickler selbst ja auch genug zu tun haben um sich nur um die Aktuellste stable version von ihren packages zu kümmern. So ein BGRAControls wird vielleicht von einigen Entwicklern auf Trunk entwickelt, aber am Ende des Tages ist das ziel das es auf Stable läuft, da zum einen die meisten Entwickler Stable benutzen, und zum anderen sich Trunk so schnell ändern kann, das man als Package entwickler keine Garantien geben kann. Wenn also packages auf trunk nicht laufen, musst du im Hinterkopf behalten das sie wahrscheinlich nie für Trunk (und erst recht nicht für die neuste Revision die vielleicht erst nach dem letzten Update des Packages rauskam) gebaut oder getestet wurde.

Gut, das erklärt natürlich auch einiges. Umso schwerer tue ich mir jetzt : Welche Package nehm ich bloss - die auch auf ARM und AARCH geht... aaaah!

Langer Rede kurzer Sinn: Wenn du ein stabiles system haben willst, benutz nicht Trunk, oder wenn du Trunk benutzen willst, beschwer dich nicht das es nicht stabil läuft. Trunk ist bleeding edge, nicht stable.

Sehr guter Tipp, aber ich fürchte, ich brauche möglicherweise die Bleeding Edge Sachen. :-/

Das ist das selbe mit z.b. Linux Mint vs Arch, wenn man Mint benutzt kann man ein sehr stabiles system erwarten, muss aber in kauf nehmen nicht die neuste Software zu haben. Bei Arch hat man immer die neuste software, dafür kann es vorkommen das nach einem Update dein System nicht mehr bootet. So ist das auch mit dem FPC, wenn du trunk benutzt hast du zwar die ganz neuen features, darfst dich aber nicht wundern wenn der panict.

Ansonsten kann ich nur meine Aussage vom Anfang widerholen, cross compilen ist nunmal scheiße, lässt sich aber ganz einfach umgehen. Und mit der stable version von Lazarus und FPC hatte ich nie Probleme mit Packages, zumindest nie welche die ich nicht lösen konnte (im schlimmsten Fall musste ich einen typen in einer zeile fixen, oder bei Indy in einer bestimmten reihenfolge kompilieren, aber nix was nicht nach ein paar stunden gelaufen wäre). Wobei das nicht ganz stimmt, manchmal trifft man auch auf packages die seit 10 jahren oder so kein Update mehr bekommen haben, da ists aber nicht verwunderlich das die nicht mehr laufen, und da sollte man sich eh fragen ob man die wirklich benutzen will. Die packages die du willst sollten aber eiegentlich problemlos auf nem Stable Lazarus laufen

Auf ARM? Hoffen wir es. Siehe LazSynaser. .....

[Warf]

Gottlob hat uns der Hersteller von dem Raspi-Clone in seinem Forum sehr geholfen, die DTB/DTS-Datei so hinzubiegen, dass uns das Kernel 3.6.18.x [...]

Naja die aktuelle LTS Kernel version ist 5.4. Die 3.6 ist halt schon 8 Jahre alt. Das erklärt dann auch:

Einige Lib's holte ich mir direkt als Binary von der Zielmaschine, das "libXtst.so" und kopierte sie ins richtige crosscompile-Verzeichnis. Das war für mich etwas unlogisch.

Den Trick den ich gemacht hätte wäre, auf der Zielplattform das projekt einmal kompilieren und ausführen (das scheint ja zu gehen) und dann mittels ldd mir alle dynamischen libs ausgeben zu lassen die das programm läd. Diese kannst du dann von der Zielplattform direkt rüber kopieren, dann hast du sie direkt von der Quelle

Einige Lib's funktionieren nur richtig unter Linux/Intel und Windows, aber nicht unter Linux/ARM,aarch64.

Meinst du pascal Packages oder Libs? Bei packages ist es halt so das FPC zwar cross plattform verfügbar ist, wenn man aber inline assembler oder lokale libs ebnutzt die nur für bestimmte systeme verfügbar sind, ist das natürlich ein problem. Eventuell sogar ein problem gegen das man nix machen kann, außer die benötigte funktionalität selbst nachbauen. Aber so ne ganz dumme Frage, wenn die vor dem Cross-Compilen lokal funktioniert haben, musste es ja schon ne funktionierende version geben

Bis das aber soweit war, mussten noch mehr Libraries compiliert werden. Wir verwenden:
BGRABitmap, BGRAControls, LazSerial, Playsoundpackage, TDINotebook, TAChartAgg/BGRA/, LazarusPkg/Print,
TDI, ToDoListLaz, Printer4Lazarus, oxml_lazarus, LazOpenGLContext, FPVectorialPkg.

Alle TAChart' Packages waren trickreich zu installieren, nämlich verlangen sie eine bestimmte Reihenfolge zum Installieren, sonst klappts wieder mal nicht.

Ich verstehe das so, das haupt problem ist das ihr auf eurem Raspi-Klon (also auf ARM) die ganzen Packages braucht. Aber die meisten dieser Packages sind zum Grafischen Darstellen, braucht ihr die wirklich auch auf dem Raspi? Der Raspi ist ja euer steuergerät, ist der auch zum grafischen darstellen da? Falls nein würden die packages ja nicht auf dem Raspi sondern nur auf dem darstellungsgerät, bzw, dann würde es sich lohnen eine cross compile lazarus version einzurichten in der du dich nicht mit denen rumschlagen musst

Übrigens, so am rand, der hauptvorteil von OpenGLContext und BGRABitmap ist das es Hardwarebeschleunigt zeichnet, der Raspi (und damit wahscheinlich auch der Klon) hat aber keine Hardware die das beschleunigen könnte. Stellt sich mir also generell die Frage wie sinnig deren verwendung ist. Aber das ist hier ja erst mal nicht das aktue problem

Was man natürlich auch machen könnte wäre das bauen zu verteilen, also das das projekt soweit vollständig via cross compile gebaut wird, und die packages auf dem Pi gebaut werden (muss ja insgesammt nur einmal pro compiler oder package version gemacht werden) und am ende auf dem Pi die sachen nur noch zusammen gelinkt werden. Sowas zu setupen dauert aber wahrscheinlich länger als einfach deine Probleme zu fixen

Das ist jetzt schon sehr viel besser als die "+5 mins compilezeit" eines BananaPi.

Also auf der Arbeit hab ich aktuell ein Projekt das zum vollständigen neu Compilen (c++) c.a. ne stunde dauert (12 Cores, 32 gig Ram). Wie wir das "problem" lösen ist ziemlich einfach, das ganze muss ja nur zum deployen einmal vollständig gebaut werden (ich denke mal das sollte bei deinem ARM build nicht groß anders sein, das meiste wird ja durch unit und integrations tests getestet), d.h. wir benutzen einfach einen Gitlab CI/CD service, sodass immer wenn wir änderungen pushen das ganze auf einem separaten server im hintergrund gebaut wird.
Dann läuft das so ab: Man arbeitet an einem Feature/Bug-Fix, pusht den, und fängt an an was anderem zu arbeiten. Nach so 20-50 minuten bekommt man dann ne mail wenn der build service (der auch die tests ausführt) durchgelaufen ist oder nicht. In der zeit kann man entweder essen gehen oder schonmal mit was anderem anfangen. Falls es einen fehler gibt kann man den beheben und wieder mit was anderem weiter machen.
Ich denke mal sowas in der Art wäre bei euch vielleicht auch die bessere option, grade da man beim reinen cross compilen ja keine tests laufen lassen kann.


Übrigens, je nach dem wie schnell die Netzwerkkarte des Klons ist, kanns gut sein das ein Netzwerkordner schneller ist als die SD-Karte (die sind verdammt langsam) und damit das kompilieren deutlich beschleunigt werden kann. Das hauptproblem beim PI ist nämlich nicht die Leistung sondern die super langsame SD-Karte

Nun, die Idee mit qemu und ARM-Ubuntu-Image gefällt mir. Aber wie gut das klappt, wird wohl erst die Praxis zeigen.

Ist zwar relativ langsam im vergleich zu native ausführung, aber wahrscheinlich deutlich schneller als der PI. Nur grafik mag QEMU gar nicht, solltest also falls möglich auf das lazarus GUI verzichten und lazbuild benutzen. Die Emulierte CPU ist zwar wahrscheinlich ein bisschen langsamer, aber dafür kannst du den vollen speed der SSD ausnutzen

Ich merke es immer wieder, dass eine Package nur "gut geht" im Betriebssystem X mit CPU Y, aber nicht wo anders.

Ja das ist eines der probleme mit einer nativen Sprache wie Pascal, zwar funktioniert das meiste cross plattform, du kannst aber auch sehr einfach plattform gebundenen code schreiben. Wenn du völlige cross-compatibilität haben willst ist Pascal mMn. auch die falsche option, dafür gibt es Script Sprachen wie Python oder VM Sprachen wie Java.
Das Motto von Lazarus ist ja auch: Write Once, Compile Anywhere und nicht Compile Once, Run Anywhere

Sehr guter Tipp, aber ich fürchte, ich brauche möglicherweise die Bleeding Edge Sachen. :-/

Reichen eventuell die Fixes-Branches? Die patchen neue features von Trunk auf die aktuelle Stable version. Wenn nicht würde es sich eventuell lohnen selbst einen solchen patch zu erstellen mit all den features die man braucht


Was ich jetzt aber noch nicht so ganz verstanden habe, dein Problem ist, du hast ein Projekt das vorher auf der hardware selbst (ARM Raspi-Klon) gebaut wurde und dort funktioniert hat, und jetzt willst du das ganze zum Cross-Compilen auf Linux bauen. Aber das problem mit welchen Packages auf welcher CPU laufen dürfte damit doch schon geklärt sein, weil es ja schonmal auf dem Pi gelaufen ist. Wo ist da also das problem? Du weist doch schon das die Packages auf ARM laufen werden, oder was hab ich da nicht richtig verstanden?

[Mathias]

Ich habe wirklich keine Lust, und ich übertreibe es hier nicht sondern meine es genau so, wie geschrieben : mich WOCHENLANG mit Libraries und missing cross compile errors abzuplagen, bis ich zum ersten Mal etwas einwandfrei compilieren kann..... wochenlang!

Bitte nicht jammern, man darf eines nicht vergessen, das fpc und Lazarus keine kommerzielle Software ist. Da wird sehr viel Zeit von Entwicklern reingesteckt, ohne das die dafür nur einen Franken bekommen.
Noch etwas :
stable = fertige Version.
trunk = Beta oder gar Alpha.

[af0815]

Ich verwende auf RasPi's und Crosscompile von Windows nach Linux(meist RasPi) täglich im beruflichen Umfeld. Das mit dem CrossCompile kann ich zu einem Teil nachvollziehen, allerdings werden Komponenten nach der Gebrauchsfähigkeit im Umfeld ausgesucht. Nach dem Motto, je weniger umso besser. Zusätlich werden alle relevanten Komponneten im jeweiligen GIT vorgehalten. Es gibt einen Uplink zur originalen Komponente und das wars. Der funktionierende Stand wird eingefroren und erst wenn Tests es klargemacht haben, das der nächste Kompiler mit den Komponneten umgehen kann, dann werden die GIT-Repos nachgezogen. Versionspinning mit fpcupdeluxe für fpc und Lazarus ist normal für mich.

Zur not habe ich mich auch schon mit Crossdebugging versucht, es aber aufgrund der Aufwandes zurückgestellt.

Die Libs der Zeilplattform liegen in einem eigenen Verzeichnis schön sortiert, da kommt nichts ins Crossdir ! Dafür gibts im Projekt unter Path die Einstellungen. Wozu das ins Crossverzeichnis ?! Ich brauche bei Lazarus gar nichts in den Debugmodus zu bringen um was zu kompilieren. WOZU ?! Ich will ja nicht den Lazarus debuggen.

Vor allen, schau dir mal die Komponentenliste an, das ist Kraut und Rüben. ToDListLaz ist für die IDE micht für das Target und die BGRAxxx ist ein Thema für sich. Man sollte versuchen gerade im Bereich ausserhalb des Desktop, soweit es nur irgendwie geht, bei den Bordmitteln zu bleiben. Die Probleme mit externen Komponenten waren bei Delphi auch schon vorhanden, da wusst man auch nie, was nach dem nächsten Bugfix (so bei Delphi vorhanden) und den Komponenten noch ging. Ein Versionsumstieg konnte schon das Ende der Komponneten bedeuten. Ich habe mich schon damals sehr zurückgehalten und nur noch Komponenten mit Quellcode zugelassen. Nur bei Lazarus und dem FPC kann man sich ein Bild machen und bekommt auch Infos - und hat den Quelltext.

[fliegermichl]

Das Problem mit checksum changed for xxx hatte ich auch mal unnd hab lange suchen müssen. In Lazarus darf es zwingend keine 2 Dateien mit gleichem Namen geben!
Ich hatte eine config.inc in verschiedenen Komponenten / Projekten. Da hat es mir ständig Fehlermeldungen gehagelt.

Nachdem ich die Dateien package_xxx_config.inc genannt hatte, waren alle Probleme weg.