Hat eigentlich jemand das offizielle fcl-image package mit fpc 3.2.2 für go32v2 schon mal übersetzt

[multiplatform-coder]

Unter Windows funktioniert das ohne Probleme, unter Linux vermutlich ebenfalls. Aber wie sieht es mit dem GO32V2-Target aus?

Hat jemand das offizielle fcl-image-Package mit FPC 3.2.2 für GO32V2 bereits erfolgreich gebaut?

Mein Problem: Der Compiler meldet "Can't find unit fpimage", obwohl fpimage.ppu im erwarteten Unit-Pfad vorhanden ist. Das gleiche passiert mit fppixlcanv.ppu.

Die Dateien sind vorhanden und haben normale Größen (fpimage.ppu ca. 190 KB). Der Compiler durchsucht auch das fcl-image-Verzeichnis.

Daher meine Frage: Gibt es Besonderheiten beim GO32V2-Target (z. B. bei langen Dateinamen, 8.3-Aliasnamen oder beim Aufbau der Units), die dazu führen können, dass vorhandene PPUs nicht verwendet werden?

[Mathias]

Hast du es mit fpcupdeluxe gebaut, da sollte alles automatisch gehen.

[multiplatform-coder]

Hast du es mit fpcupdeluxe gebaut, da sollte alles automatisch gehen.

Nein hab ich nicht, ich habe das Package aus der offiziellen Installation dabei tritt das genannte Problem auf. FPCupDeluxe habe ich noch nicht ausprobiert.

[af0815]

Nochmals, was sagt ppudump über die ppu, die nicht gefunden wurde ?

Wenn die system ppu einen anderen Hash hat, wird die ignoriert. Go32v2 ist nicht unbedingt ein Mainstream Target. Da kann sich die Frage stellen, ob die richtig gebaut wurde, deswegen mit ppudump die Dateien prüfen.

Ich baue Cross-Compiler miitlerweile immer mit fpcupdeluxe. Damit kann ich sicher sein, das der Compiler und die ganzen Units zusammenpassen.

[multiplatform-coder]

Nochmals, was sagt ppudump über die ppu, die nicht gefunden wurde ?

Wenn die system ppu einen anderen Hash hat, wird die ignoriert. Go32v2 ist nicht unbedingt ein Mainstream Target. Da kann sich die Frage stellen, ob die richtig gebaut wurde, deswegen mit ppudump die Dateien prüfen.

Ich baue Cross-Compiler miitlerweile immer mit fpcupdeluxe. Damit kann ich sicher sein, das der Compiler und die ganzen Units zusammenpassen.

Ich habe ppudump inzwischen ausprobiert. Es erzeugt eine sehr große Textausgabe (bei fpimage.ppu über 1 MB), daher bin ich unsicher, welche Teile davon für die Diagnose relevant sind.

Ich sehe darin auf den ersten Blick keine Hash-Werte.

Welche Abschnitte der ppudump-Ausgabe interessieren dich? Reichen die Headerinformationen oder soll ich bestimmte Bereiche herauskopieren?

Falls die komplette Ausgabe benötigt wird, kann ich sie auf einen Filehoster hochladen und den Link hier posten, da ich in diesem Forum keine Dateien anhängen kann.

[af0815]

Ich habe ppudump inzwischen ausprobiert. Es erzeugt eine sehr große Textausgabe (bei fpimage.ppu über 1 MB), daher bin ich unsicher, welche Teile davon für die Diagnose relevant sind.

Ich sehe darin auf den ersten Blick keine Hash-Werte.

Welche Abschnitte der ppudump-Ausgabe interessieren dich? Reichen die Headerinformationen oder soll ich bestimmte Bereiche herauskopieren?

Wie im Beispiel sind es die Zeilen nach dem Start, siehe viewtopic.php?f=10&t=17856&p=156344#p156344 , dort ist auch ersichtlich, wo man den CRC findet. Es ist relativ einfach, es ist in den ersten 100 Zeilen zu finden. Die Bereiche Header und Interface Section sind für das am wichtigsten. Ausserdem sieht man hier, was alles an restlichen ppu's verwendet wird.

[multiplatform-coder]

Hier sind die ersten ca. 100 Zeilen der ppudump-Ausgabe von fpimage.ppu:

PPU-Analyser Version 3.2.2
Copyright (c) 1998-2013 by the Free Pascal Development Team

Analyzing f:\fpc\units\go32v2\fcl-image\fpimage.ppu (v207)

Header
-------
Compiler version : 3.2.2
Target processor : i386
Target operating system : GO32V2
Unit flags : init, final, static_linked, little_endian, release, local_symtable
FileSize (w/o header) : 190916
Checksum : 92A5B626
Interface Checksum : 851FA4EE
Indirect Checksum : 292668C3
Definitions stored : 516
Symbols stored : 2191

Interface section
------------------
Module Name: FPImage

Source file 1 : fpimage.pp 2020/06/24 19:20:12
Source file 2 : fpcolors.inc 2019/12/09 10:29:36
Source file 3 : fpimage.inc 2018/07/09 13:30:40
Source file 4 : fphandler.inc 2018/01/13 12:04:42
Source file 5 : fppalette.inc 2010/02/13 15:47:08
Source file 6 : fpcolcnv.inc 2019/04/20 22:24:18
Source file 7 : fpcompactimg.inc 2012/06/19 20:25:48
Uses unit: System (Crc: 3C3C863B, IntfcCrc: 7F6EB7FB, IndCrc: D031AB0F)
Uses unit: objpas (Crc: E6BD4836, IntfcCrc: C08599A8, IndCrc: D933551E)
Uses unit: sysutils (Crc: 056171BC, IntfcCrc: CB61EB98, IndCrc: 0F84435C)
Uses unit: Classes (Crc: 7EE1DCE2, IntfcCrc: 76A62227, IndCrc: 05F543CE)
Link unit object file: fpimage.o (static )
DerefMapsize: 5
DerefMap[0] = SYSTEM
DerefMap[1] = CLASSES
DerefMap[2] = TYPES
DerefMap[3] = SYSUTILS
DerefMap[4] = OBJPAS
Derefdata length: 29512

Interface symtable
----------------------
Symtable options: Has operator, Needs init final table

Interface definitions
----------------------
** Definition Id 0 **
Object/Class definition
Type symbol : (0) SymId 58
DefOptions :
DefStates : VMT Written, RTTITable Used, InitTable Used, RTTITable Written, InitTable Written
Name of Class : TFPCustomImageReader
Import lib/pkg :
Options : HasVirtual, HasPrivate, HasProtected, HasConstructor, HasDestructor, HasVMT
Type : class
Helper Type : none
External name :
DataSize : 24
PaddingSize : 0
FieldAlign : 0
RecordAlign : 4
RecordAlignMin : 0
VmtField : (8) Unit 0, SymId 4205
Ancestor Class : (17) DefId 175
Abstract methods : 2
VMT entries: 18
(466) Unit 0, DefId 752
Visibility: public
(475) Unit 0, DefId 754
Visibility: public
(484) Unit 0, DefId 756
Visibility: public
(493) Unit 0, DefId 757
Visibility: public
(502) Unit 0, DefId 758
Visibility: public
(511) Unit 0, DefId 784
Visibility: public
(520) Unit 0, DefId 785
Visibility: public
(529) Unit 0, DefId 786
Visibility: public
(538) Unit 0, DefId 787
Visibility: public
(547) Unit 0, DefId 788
Visibility: public
(556) Unit 0, DefId 803
Visibility: public
(565) Unit 0, DefId 804
Visibility: public
(574) Unit 0, DefId 805
Visibility: public
(583) DefId 176
Visibility: protected
(589) DefId 192
Visibility: public
(595) DefId 188

[af0815]

Die entsprechende system.ppu braucht man auch.

Dort sollte die Checksums "Uses unit: System (Crc: 3C3C863B, IntfcCrc: 7F6EB7FB, IndCrc: D031AB0F)" ident sein. Wenn das so ist, passen die ppu's zusammen. Dann muss man weitersuchen beim FPC selbst.

[multiplatform-coder]

Hier noch die angeforderte system.ppu

Habe mich vorhin vertippt Sorry, hoffenltich war noch niemand hier seit dem lezten Post von mir bei dem ich eine "unhandled Exception" bekam, hier nun die richtige log Datei:

PPU-Analyser Version 3.2.2
Copyright (c) 1998-2013 by the Free Pascal Development Team

Analyzing system.ppu (v207)

Header
-------
Compiler version : 3.2.2
Target processor : i386
Target operating system : GO32V2
Unit flags : init, static_linked, little_endian, release, local_threadvars, local_symtable
FileSize (w/o header) : 898025
Checksum : 3C3C863B
Interface Checksum : 7F6EB7FB
Indirect Checksum : D031AB0F
Definitions stored : 2651
Symbols stored : 8192

Interface section
------------------
Module Name: System

Features:
heap
init_final
rtti
classes
exceptions
exitcode
ansistrings
widestrings
textio
consoleio
fileio
random
variants
objects
dynarrays
threading
commandargs
processes
stackcheck
dynlibs
softfpu
objectivec1
resources
unicodestring
Source file 1 : system.pp 2018/07/09 18:26:54
Source file 2 : systemh.inc 2020/12/31 01:04:50
Source file 3 : sysosh.inc 2005/06/07 11:47:56
Source file 4 : rtldefs.inc 2013/09/06 13:04:34
Source file 5 : filerec.inc 2017/11/05 21:30:52
Source file 6 : textrec.inc 2017/11/05 21:30:52
Source file 7 : innr.inc 2017/11/27 18:41:50
Source file 8 : cpuh.inc 2018/07/11 16:19:42
Source file 9 : cpuinnr.inc 2018/07/11 16:19:42
Source file 10 : mathh.inc 2018/06/29 22:51:34
Source file 11 : currh.inc 2012/08/20 22:15:08
Source file 12 : ustringh.inc 2016/06/03 23:25:50
Source file 13 : setjumph.inc 2013/12/16 12:12:38
Source file 14 : rttih.inc 2017/12/09 18:18:20
Source file 15 : objpash.inc 2017/12/02 19:16:34
Source file 16 : varianth.inc 2020/10/11 16:08:34
Source file 17 : dynarrh.inc 2017/08/11 22:37:38
Source file 18 : compproc.inc 2020/11/25 23:24:42
Source file 19 : heaph.inc 2016/05/11 16:32:04
Source file 20 : threadh.inc 2020/12/18 00:44:28
Source file 21 : dynlibh.inc 2015/09/29 18:30:28
Source file 22 : resh.inc 2020/11/26 22:51:30
Source file 23 : excepth.inc 2015/03/28 15:09:38
Source file 24 : portsh.inc 2018/07/09 16:55:22
Source file 25 : system.inc 2020/02/04 01:16:04
Source file 26 : sysos.inc 2007/08/09 20:51:16
Source file 27 : i386.inc 2020/12/30 15:53:12
Source file 28 : fastmove.inc 2017/08/04 22:52:00
Source file 29 : generic.inc 2020/12/16 00:32:00
Source file 30 : set.inc 2013/09/29 12:53:50
Source file 31 : genset.inc 2012/03/29 22:34:58
Source file 32 : math.inc 2017/08/21 15:29:30
Source file 33 : genmath.inc 2020/12/30 16:07:18
Source file 34 : gencurr.inc 2012/08/20 22:15:08
Source file 35 : sstrings.inc 2017/08/11 22:37:38
Source file 36 : flt_conv.inc 2016/10/02 14:57:00
Source file 37 : flt_core.inc 2016/10/02 14:57:00
Source file 38 : flt_pack.inc 2013/11/02 19:44:48
Source file 39 : flt_pack.inc 2013/11/02 19:44:48
Source file 40 : int64p.inc 2017/02/19 21:15:16
Source file 41 : int64.inc 2018/03/18 00:44:46
Source file 42 : astrings.inc 2017/03/18 16:38:52
Source file 43 : ustrings.inc 2018/08/19 16:57:52
Source file 44 : aliases.inc 2017/02/19 14:47:32
Source file 45 : rttidecl.inc 2018/09/26 14:50:48
Source file 46 : dynarr.inc 2018/08/07 18:34:58
Source file 47 : objpas.inc 2018/09/26 14:50:48
Source file 48 : except.inc 2015/03/28 15:09:38
Source file 49 : variant.inc 2015/09/15 13:51:40
Source file 50 : rtti.inc 2020/12/13 23:52:14
Source file 51 : setjump.inc 2013/12/16 12:12:38
Source file 52 : sysheap.inc 2007/07/04 21:46:48
Source file 53 : heap.inc 2019/11/05 17:33:48
Source file 54 : thread.inc 2020/12/18 00:44:28
Source file 55 : threadvr.inc 2016/07/01 16:18:30
Source file 56 : dynlib.inc 2015/09/29 18:30:28
Source file 57 : sysfile.inc 2014/11/23 23:49:30
Source file 58 : text.inc 2020/12/30 16:07:56
Source file 59 : file.inc 2015/08/28 20:49:08

[af0815]

Da passt alles zusammen, also ist der Teil in Ordnung.
Dann am besten Mal den Tip von Mattias mit FPC -vt machen. Das vt in deine Zeilen zum kompilieren einfügen, dann kommt elend viel vom FPC, aber er sagt, was er sucht und nicht findet.

[multiplatform-coder]

Kann ich tun. Hier ist der Link zu meinem Fileserver: https://drive.google.com/file/d/157arPa ... sp=sharing

Da gibt es eine Datei compilat.zip. Die enthält 4 Dateien:

1x Tstpix.pas eine Minimaldatei nur mit uses fppixl~1;
1x Tstpix1.pas eine Minimaldatei mit uses fppixlcanv;
1x zcompile.log die erste compilierte Datei mit dem kurzen Dateinamen
1x zcompile1.log die Tstpix1.pas mit dem langen Dateinamen fppixlcanv in der Uses Klausel

[af0815]

bei zcompile.log hat er zwei Sachen
-> er findet "f:\fpc\units\go32v2\fcl-image\" nicht. Daher den Pfad wo normalerweise die ppu's aus fcl-image abgelegt werden.
-> der Tildecharakter ~ ist im Pascalquelltext nicht gültig, auch wenn es vom Filesystem so ver/ge-kürzt wird.

bei zcompile1.log hat er folgende Sachen
-> er findet "f:\fpc\units\go32v2\fcl-image\" nicht. Daher den Pfad wo normalerweise die ppu's aus fcl-image abgelegt werden.
-> die Pfade werden teilweise durch die Tilde als Kürzungzeichen verhunzt. f:\fpc\units\go32v2\fcl-im~1\ sollte vermutlich f:\fpc\units\go32v2\fcl-image\ heissen. Vermutlich findet er durch die Kürzung nicht den eigentlich erwarteten Dateinamen. Und damit erklärt sich auch, warum er "f:\fpc\units\go32v2\fcl-image\" nicht findet.

-------------
Insgesamt würde ich sagen, du solltest das mit den Dateinamen in den Griff bekommen, dann wird es vermutlich ruhiger.
Sind diese Kürzungen auch im Dateisystem selbst ersichtlich ?
Ich kenne den GO 32 V2 DOS extender leider nicht und damit auch nicht die Besonderheiten desselben.

[Socke]

Sind diese Kürzungen auch im Dateisystem selbst ersichtlich ?

Das lässt sich mit dem Befehl dir /x abfragen.
Unter Windows sind langen und kurzen Dateinamen eigentlich äquivalent - in etwa als hätte man unter Linux zwei Hard Links auf eine Datei/ein Verzeichnis.

Wichtig sollte daher vor allem sein, dass die Pfadangaben konsistent zu dem Compiler sind.
Läuft der Compiler in der GO32V2-Umgebung und versteht damit nur die 8.3-Pfade?

[multiplatform-coder]

Da will ich mal meine Einstellungen der dosbox-x.conf hier rein stellen:
[dosbox]
logfile=dosbox.log
usescancodes=true
securemode=false
longnames=true ;will lange Dateinamen zulassen
ffn=true
memsize=128 ; optimal für alte DOS-Tools
xms=true
ems=true
umb=true

[keyboard]
keyboardlayout=auto

[cpu]
core=normal
cputype=pentium
cycles=max

[dos]
lfn=true
emm=true

[dpmi]
dpmi.memory=32768 ; 32 MB DPMI-RAM, sicher für Protected Mode

[sdl]
fullscreen=false
usescancodes=true
clipboard=both
autolock=FALSE

[autoexec]
rem Mount-Verzeichnisse
rem mount a e:\users\konta\BP\install
mount e e:\users\konta\fpc32\tycoon\
mount f c:\dosimages\
imgmount h c:\dosimages\fd14full.img
imgmount g c:\dosimages\dos.img -t hdd fat

[multiplatform-coder]

Sind diese Kürzungen auch im Dateisystem selbst ersichtlich ?

Das lässt sich mit dem Befehl dir /x abfragen.
Unter Windows sind langen und kurzen Dateinamen eigentlich äquivalent - in etwa als hätte man unter Linux zwei Hard Links auf eine Datei/ein Verzeichnis.

Wichtig sollte daher vor allem sein, dass die Pfadangaben konsistent zu dem Compiler sind.
Läuft der Compiler in der GO32V2-Umgebung und versteht damit nur die 8.3-Pfade?

Ja, in der Dosbox-x, aus dieser heraus gestartet. Falls ihr aufgrund der Compilerausgabe vermutet, dass dennoch eine DOSBox-X-Einstellung oder GO32V2-Besonderheit die Ursache sein könnte, freue ich mich über Hinweise.

Ich habe den Test bewusst in zwei Varianten durchgeführt.

tstpix.pas verwendet den 8.3-Unitnamen fppixl~1.
tstpix1.pas verwendet den langen Unitnamen fppixlcanv.