FPC unter Windows kompilieren - bricht mit Fehler ab

[af0815]

Ich habe folgendes Problem beim kompilieren des aktuellen SVN-Standes (16675) des FPC unter W7Prof32:

Code: Alles auswählen

sysutils.pp(824,3) Warning: Symbol "GetLocaleFormatSettings" is not portable
dateutil.inc(1975,25) Warning: Symbol "DateSeparator" is deprecated
dateutil.inc(1976,25) Warning: Symbol "DateSeparator" is deprecated
dateutil.inc(1978,25) Warning: Symbol "TimeSeparator" is deprecated
dateutil.inc(1979,25) Warning: Symbol "TimeSeparator" is deprecated
dateutil.inc(1980,28) Warning: Symbol "DecimalSeparator" is deprecated
cvarutil.inc(423,34) Warning: Symbol "ThousandSeparator" is deprecated
cvarutil.inc(424,34) Warning: Symbol "DecimalSeparator" is deprecated
fgl.pp(128,38) Error: Generics without specialization cannot be used as a type f
or a variable
fgl.pp(163,44) Error: Generics without specialization cannot be used as a type f
or a variable
fgl.pp(198,54) Error: Generics without specialization cannot be used as a type f
or a variable
fgl.pp(346,1) Fatal: There were 3 errors compiling module, stopping
Fatal: Compilation aborted
make[7]: *** [buildrtl.ppu] Error 1
make[7]: Leaving directory `X:/Pascal/fpcbuild/fpcsrc/rtl/win32'
make[6]: *** [win32_all] Error 2
make[6]: Leaving directory `X:/Pascal/fpcbuild/fpcsrc/rtl'
make[5]: *** [rtl] Error 2
make[5]: Leaving directory `X:/Pascal/fpcbuild/fpcsrc/compiler'
make[4]: *** [next] Error 2
make[4]: Leaving directory `X:/Pascal/fpcbuild/fpcsrc/compiler'
make[3]: *** [ppc1.exe] Error 2
make[3]: Leaving directory `X:/Pascal/fpcbuild/fpcsrc/compiler'
make[2]: *** [cycle] Error 2
make[2]: Leaving directory `X:/Pascal/fpcbuild/fpcsrc/compiler'
make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory `X:/Pascal/fpcbuild/fpcsrc'
make: *** [build-stamp.i386-win32] Error 2

Mein Aufruf, der bis jetzt funktioniert hatte (warum auch immer)

Code: Alles auswählen

make clean PP=X:\Pascal\Pascal\binaries\i386-win32\ppc386.exe
make install INSTALL_BASEDIR=X:\Pascal\Pascal\lazarus\fpc\svn PP=X:\Pascal\Pascal\binaries\i386-win32\ppc386.exe

Was mir komisch vorkommt, ist die bedingte Kompilierung

Code: Alles auswählen

{$ifndef VER2_4}
    procedure Assign(Source: TFPGList);  <<<< Hier Fehler
{$endif VER2_4}

die ist erst mit SVN 16429 (25.11.2010) dazugekommen.

Muß ich auf der Kommandozeile noch was beim Kompilieren mitgeben ?!

[marcov]

Und X:\Pascal\Pascal\binaries\i386-win32\ppc386.exe ist 2.4.2, und nur 2.4.2?

[af0815]

Und X:\Pascal\Pascal\binaries\i386-win32\ppc386.exe ist 2.4.2, und nur 2.4.2?

sollte 2.5.1 von Oktober sein, muß es aber prüfen - Gute Idee.

[Socke]

Und X:\Pascal\Pascal\binaries\i386-win32\ppc386.exe ist 2.4.2, und nur 2.4.2?

Es wird nur garantiert, dass der Compiler sich mit der neusten stabilen Version übersetzen lässt. Ich habs auch schon erlebt, dass die aktuelle SVN-Version sich nicht selbst übersetzen kann.

Mein Aufruf, der bis jetzt funktioniert hatte (warum auch immer)

Code: Alles auswählen

make clean PP=X:\Pascal\Pascal\binaries\i386-win32\ppc386.exe
make install INSTALL_BASEDIR=X:\Pascal\Pascal\lazarus\fpc\svn PP=X:\Pascal\Pascal\binaries\i386-win32\ppc386.exe

Ich nutze INSTALL_PREFIX=~/newfpc erfolgreich und statt mit PP gebe ich mit FPC den Startcompiler an.

Was mir komisch vorkommt, ist die bedingte Kompilierung

Code: Alles auswählen

{$ifndef VER2_4}
    procedure Assign(Source: TFPGList);  <<<< Hier Fehler
{$endif VER2_4}

die ist erst mit SVN 16429 (25.11.2010) dazugekommen.

Generics werden doch erst ab Version 2.4 unterstützt. Daher sehe ich hier kein Problem, das wäre wohl eher woanders zu suchen.

[af0815]

Und X:\Pascal\Pascal\binaries\i386-win32\ppc386.exe ist 2.4.2, und nur 2.4.2?

sollte 2.5.1 von Oktober sein, muß es aber prüfen - Gute Idee.

Es ist 2.5.1 vom 5.10.2010, das kann es also nicht sein. Der sollte Generics können.

Edit: mit SVN 16428 gehts.

[Socke]

Es ist 2.5.1 vom 5.10.2010, das kann es also nicht sein. Der sollte Generics können.

Es wird aber nicht garantiert, dass sich svn/trunk selbst übersetzen kann. Wenn er’s kann, ist’s schön, mehr aber auch nicht. Stable (z.Z. also 2.4.2) kann immer svn/trunk übersetzen.

[af0815]

Es wird aber nicht garantiert, dass sich svn/trunk selbst übersetzen kann. Wenn er’s kann, ist’s schön, mehr aber auch nicht. Stable (z.Z. also 2.4.2) kann immer svn/trunk übersetzen.

Das glaube ich dir, das es mit einem 2.4.x geht, denn genau dann ist das durch das if nicht aktiv und somit ist es widersinnig, wenn das eingebaut wurde, ohne das es gebraucht wird (oder werden kann). Es kam erst kürzlich hinzu.

[Socke]

Das glaube ich dir, das es mit einem 2.4.x geht, denn genau dann ist das durch das if nicht aktiv und somit ist es widersinnig, wenn das eingebaut wurde, ohne das es gebraucht wird (oder werden kann). Es kam erst kürzlich hinzu.

Dann ist es wohl dazu gedacht, dass man den Compiler auch später noch mit einem älteren Compiler übersetzen kann. Ich weiß nicht, inwiefern das gefordert oder nur gewünscht ist, aber die FPC-Quelltexte enthalten eine Menge von solchen Direktiven.

[marcov]

Es wird aber nicht garantiert, dass sich svn/trunk selbst übersetzen kann. Wenn er’s kann, ist’s schön, mehr aber auch nicht. Stable (z.Z. also 2.4.2) kann immer svn/trunk übersetzen.

Das glaube ich dir, das es mit einem 2.4.x geht, denn genau dann ist das durch das if nicht aktiv und somit ist es widersinnig, wenn das eingebaut wurde, ohne das es gebraucht wird

Es kann schon gebraucht werden, weil ein Snapshot build FPC 3 oder 4 mal baut. Nur der erste ist mit 2.4.2, danach compiliert den generierter compiler sich selbst. (und noch ein oder zwei mal um vergleichen und Optimalizationen durch propagieren zu lassen) .

Darum verstehe ich auch nicht ganz was Socke sagt. trunk kann sich selbst (fast) immer übersetzen. (nur ab und zu ist funktioniert das nicht, und eben weniger mit -O-). Das 2.5.1 version r<x> sich selbst compilieren kann ist teil der normaler Bau Prozedur.

[Socke]

Es kann schon gebraucht werden, weil ein Snapshot build FPC 3 oder 4 mal baut. Nur der erste ist mit 2.4.2, danach compiliert den generierter compiler sich selbst. (und noch ein oder zwei mal um vergleichen und Optimalizationen durch propagieren zu lassen) .

Darum verstehe ich auch nicht ganz was Socke sagt. trunk kann sich selbst (fast) immer übersetzen. (nur ab und zu ist funktioniert das nicht, und eben weniger mit -O-). Das 2.5.1 version r<x> sich selbst compilieren kann ist teil der normaler Bau Prozedur.

De facto hatte ich einen FPC 2.5.1 der einen neueren svn/trunk nicht übersetzen konnte (kann natürlich auch an der Optimierung gelegen haben, die dank fpc.cfg immer Eingeschaltet wird). Der Compiler wird -- wie du richtigerweise sagst -- mindestens dreimal gebaut (zweimal von sich selbst). Lässt sich daraus schließen, dass svn/trunk sich immer selbst, nicht aber immer einen neueren Compiler erstellen kann?

[marcov]

Es kann schon gebraucht werden, weil ein Snapshot build FPC 3 oder 4 mal baut. Nur der erste ist mit 2.4.2, danach compiliert den generierter compiler sich selbst. (und noch ein oder zwei mal um vergleichen und Optimalizationen durch propagieren zu lassen) .

Darum verstehe ich auch nicht ganz was Socke sagt. trunk kann sich selbst (fast) immer übersetzen. (nur ab und zu ist funktioniert das nicht, und eben weniger mit -O-). Das 2.5.1 version r<x> sich selbst compilieren kann ist teil der normaler Bau Prozedur.

De facto hatte ich einen FPC 2.5.1 der einen neueren svn/trunk nicht übersetzen konnte (kann natürlich auch an der Optimierung gelegen haben, die dank fpc.cfg immer Eingeschaltet wird). Der Compiler wird -- wie du richtigerweise sagst -- mindestens dreimal gebaut (zweimal von sich selbst). Lässt sich daraus schließen, dass svn/trunk sich immer selbst, nicht aber immer einen neueren Compiler erstellen kann?

Ja. Mit diesem System gibst nur zwei Möglichkeiten:

1) 2.4.2
2) 2.5.1 in exakt dieser Version.

Wenn jede 2.5.1 Compiler jede 2.5.1 Quellen kompilieren konnte, gebe es heute etwa (r16880-r13800 + 2.4.2)^2= etwa 9 Millionen mögliche Kombinationen. (aber nicht alle Revisions ändern der Kompiler natürlich). Also dieser Prinzip macht der Versionsmatrix um einen Faktor = 4.5M einfacher.

Dies meint auch das wenn man alle Release Quellen hat, man in Theorie mit Turbo Pascal 7 FPC herstellen kann. (TP kann 0.99.x übersetzen. Es kann auch 1.0.0 übersetzen, aber nicht ohne Tricks. Das Speicher reicht sonst nicht). Und dann 1.0.2,1.0.4, 1.0.6, 1.0.10,2.0,2.0.2,2.0.4,2.2.0,.2.2.2,2.2.4,.2.4.0,2.4.2 und dann endlich 2.5.1.

P.s. der Anzahl Kompilierungen ändert sich. In Prinzip 3. (ein bootstrap, ein recompile, und noch ein um der Binäre Stabilität prüfen zu koennen mit compare), aber mit release=1 kann da noch ein eine WPO Pass (inter-Unit optimizationen) und am enden einen RTL Pass (smartlinking RTL), dazu kommen.

[Socke]

P.s. der Anzahl Kompilierungen ändert sich. In Prinzip 3. (ein bootstrap, ein recompile, und noch ein um der Binäre Stabilität prüfen zu koennen mit compare), aber mit release=1 kann da noch ein eine WPO Pass (inter-Unit optimizationen) und am enden einen RTL Pass (smartlinking RTL), dazu kommen.

Was ist denn an Optimierungen in den Makefiles standardmäßig aktiv? Ich kann nicht wirklich gut makefiles lesen, und übersetze immer (ohne Probleme) mit OPT/CROSSOPT="-CX -XX -O3". Durch ein Standard -dRELEASE kommt durch meine fpc.cfg noch -Xs hinzu.

[marcov]

P.s. der Anzahl Kompilierungen ändert sich. In Prinzip 3. (ein bootstrap, ein recompile, und noch ein um der Binäre Stabilität prüfen zu koennen mit compare), aber mit release=1 kann da noch ein eine WPO Pass (inter-Unit optimizationen) und am enden einen RTL Pass (smartlinking RTL), dazu kommen.

Was ist denn an Optimierungen in den Makefiles standardmäßig aktiv? Ich kann nicht wirklich gut makefiles lesen, und übersetze immer (ohne Probleme) mit OPT/CROSSOPT="-CX -XX -O3". Durch ein Standard -dRELEASE kommt durch meine fpc.cfg noch -Xs hinzu.

Das alles weiß ich auch nicht genau. Ich glaube das normal alles meistens aus ist, aber die release building Scripts fuegen RELEASE=1 eins zu.

Also

make all RELEASE=1

ich glaube das das Smartlinking und Optimierungen (O2 denke ich) hinzufügt.


P.s. gestern würde PPU Revision inkrementiert weil das Generics Streamingformat geändert wurde. Das hat wohl den Bruch in 2.5.1->2.5.1 Kompatibilität verursacht.

[af0815]

Ich habe folgendes für das erstellen des FPC gelernt:

Der FPC aus dem SVN kann nur dann verläßlich kompiliert werden, wenn als Bootstrap (Start-) Comüpiler der ppc386.exe von der letzten stabilen Release verwendet wird. NUR dann kann er verläßlich sich selbst kompilieren. Warum -> der Compiler kompiliert sich 3 mal selbst, beim ersten Mal mit Hilfe des Bootstrapcompiler. Dann überprüft er die Versionen und macht die Bibliotheken fertig. Es ist kein muß, das ein fpc 2.5.1 einen fpc 2.5.1 kompilieren kann. Bei meinem Problem bin ich über einen Trick gestoplert, wie die Entwickler es schaffen neue Features einbauen, die es vorher nicht gegeben hat.

Daher: für die aktuelle Version von 2.5.1 aus dem SVN zum kompilieren braucht man zwingend den FPC aus dem 2.4.2 Paket.

Frühere Versionen (wie auch ältere) können gehen, müßen aber nicht.