Cross-kompilierte .exe startet nicht mehr...?

Für alles, was in den übrigen Lazarusthemen keinen Platz, aber mit Lazarus zutun hat.
Antworten
Sieben
Beiträge: 202
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.2.0, FPC 3.2.2
CPU-Target: i386

Cross-kompilierte .exe startet nicht mehr...?

Beitrag von Sieben »

Eine bislang erfolgreich für Win32 cross-kompilierte .exe zeigt beim Aufruf auf dem Zielsystem Win10/64 auf einmal nur noch ein kurzes Zucken des Wait-Cursor, keine Fehlermeldung, nada. Ebenso auf einem Win7/32, das hier noch rumfliegt. Es ist eine kleine Datenbankanwendung mit SQLite3, die aber wie gesagt auf dem Zielsystem bereits seit Wochen fehlerfrei läuft, die dll's sind am Platz. Andere Projekte können aber nach wie vor erfolgreich für Win32 kompiliert werden. Ich habe die entsprechenden Einstellungen hoch und runter verglichen, aber so langsam fällt mir nichts mehr ein. Hatte das vielleicht hier auch schon mal jemand...?

Benutzeravatar
fliegermichl
Lazarusforum e. V.
Beiträge: 1432
Registriert: Do 9. Jun 2011, 09:42
OS, Lazarus, FPC: Lazarus Fixes FPC Stable
CPU-Target: 32/64Bit
Wohnort: Echzell

Re: Cross-kompilierte .exe startet nicht mehr...?

Beitrag von fliegermichl »

In einer DOS Box starten. Vielleicht gibt es eine Fehlermeldung.
Die andere Möglichkeit wäre das Lazarus Logging zu aktivieren.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Cross-kompilierte .exe startet nicht mehr...?

Beitrag von af0815 »

Ich kenne 2 Fälle davon:

a) mit der DLL und davon abhängigen DLLs ist was passiert -> wie Fliegermichl sagt - eine Commandline öffnen und das Programm von dort starten
b) In der LPR Datei des Projektes ist die Erstellung der Fenster durcheinander gekommen oder verschwunden.
...
Application.CreateForm(TFrmMain, FrmMain);
Application.Run;
...
Es ist mir schon mal ein CreateForm verschwunden bzw. war plötzlich an der falschen Stelle. Wenn es an der falschen Stelle ist, sieht man meistens eine Fehlermeldung von anderen Fenstern deren Abhängigkeiten plötzlich nicht mehr stimmen. Fehlt der Eintrag komplett, so sieht man gar nichts :shock:
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Sieben
Beiträge: 202
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.2.0, FPC 3.2.2
CPU-Target: i386

Re: Cross-kompilierte .exe startet nicht mehr...?

Beitrag von Sieben »

Vielen Dank erst mal. Start über Commandline ergibt ebenfalls sprichwörtlich nichts, keine Meldung, gar nichts; lpr ist soweit in Ordnung (Programm startet auf Linux auch ordnungsgemäß); ein erster Versuch mit TEventLog im Create des ersten Forms (bzw DataModuls) tut wie erwartet unter Linux, hinterlässt aber auch keinerlei Spuren auf dem Zielsystem.

Sieben
Beiträge: 202
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.2.0, FPC 3.2.2
CPU-Target: i386

Re: Cross-kompilierte .exe startet nicht mehr...?

Beitrag von Sieben »

So, jetzt konnte ich ihr mit LazLogger und Eingabeaufforderung (ich habe es bislang nicht geschafft, ihn in eine Datei schreiben zu lassen, trotz Vorgehen wie hier beschrieben) doch noch die entscheidende Meldung entlocken:

"Exception occured: dbConn: unable to connect to database"

Stellt sich raus, dass die Connection auf Active=True stand, obwohl dieses Property bei mir wohlweislich ein 'stored False' hat und das bislang auch immer brav beachtet hat. Ein Blick in die lfm zeigte dann allerdings, dass jetzt aber mal die zugehörige TSQLTransaction ihr Active gespeichert und damit beim Laden des Projekts offenbar ihrerseits die Connection geöffnet hat... und da das Datenmodul als erstes erzeugt wird, ist die Exception anscheinend noch nicht richtig verarbeitet und angezeigt worden(?).

Benutzeravatar
fliegermichl
Lazarusforum e. V.
Beiträge: 1432
Registriert: Do 9. Jun 2011, 09:42
OS, Lazarus, FPC: Lazarus Fixes FPC Stable
CPU-Target: 32/64Bit
Wohnort: Echzell

Re: Cross-kompilierte .exe startet nicht mehr...?

Beitrag von fliegermichl »

"stored false" bedeutet nicht, daß der Wert false in die lfm Datei geschrieben wird, sondern, daß die Property nicht in der lfm Datei gespeichert werden soll.

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Cross-kompilierte .exe startet nicht mehr...?

Beitrag von Socke »

fliegermichl hat geschrieben:
Fr 4. Mär 2022, 10:32
"stored false" bedeutet nicht, daß der Wert false in die lfm Datei geschrieben wird, sondern, daß die Property nicht in der lfm Datei gespeichert werden soll.
Das bringt nur nichts, wenn eine andere Komponente die Eigenschaft ändert oder die Exception nicht ausgegeben wird.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

Sieben
Beiträge: 202
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.2.0, FPC 3.2.2
CPU-Target: i386

Re: Cross-kompilierte .exe startet nicht mehr...?

Beitrag von Sieben »

"stored false" bedeutet nicht, daß der Wert false in die lfm Datei geschrieben wird, sondern, daß die Property nicht in der lfm Datei gespeichert werden soll.
Yes, I know... - es führt aber hier genau zum gewünschten Ergebnis, da sich Datenbankkomponenten ja erst auf Anforderung mit der Datenbank verbinden. Erhalten sie keine, verbinden sie sich auch nicht. Jetzt hat nach TSQLConnection und TSQLQuery auch das Property Active der TSQLTransaction den entsprechenden Zusatz erhalten.

Es war wie gesagt in vielen Wochen mit vielen problemlosen Updates das erste Mal, dass diese Konstellation aufgetreten ist. Und ich habe es auch noch mal kurz getestet - eine Exception im Create-Handler führt zur sofortigen 'Rückabwicklung' des Programms, ohne dass - zumindest unter Windows - irgendeine Fehlermeldung an die Oberfläche gelangt. Unter Linux im Prinzip genauso, nur dass ich dort noch eine SIGSEV-Meldung aufgrund eines Folgefehlers erhalten hätte, die als Hinweis wohl ausgereicht hätte. Wenn's nicht der Entwicklungsrechner gewesen wäre, bei dem die Datenbank natürlich aaO war...

Antworten