Hi,

I am trying to update my FPC from SVN, but for some reason I keep on getting a compilation error. The last build was from 21955 (23rd July 2012). See below for the makefile output.

Regards, Darius

C:lazarusfpctrunk>make all
make compiler_cycle RELEASE=1
make[1]:
Entering directory `C:/lazarus/fpc/trunk'
make -C compiler
cycle
make[2]: Entering directory `C:/lazarus/fpc/trunk/compiler' make
tempclean ppc3.exe
make[3]: Entering directory
`C:/lazarus/fpc/trunk/compiler'
/pp/bin/i386-win32/rm.exe -f
ppcross386.exe ppc.exe ppc1.exe ppc2.exe ppc3.exe ./msg2inc.exe pp1.wpo pp2.wpo
make 'OLDFPC=' next CYCLELEVEL=1
make[4]: Entering directory
`C:/lazarus/fpc/trunk/compiler'
make rtlclean rtl
make[5]: Entering
directory `C:/lazarus/fpc/trunk/compiler'
make -C
C:/lazarus/fpc/trunk/rtl clean
make[6]: Entering directory
`C:/lazarus/fpc/trunk/rtl'
/pp/bin/i386-win32/rm.exe -f
fpcmade.i386-win32 Package.fpc ppas.sh script.res
link.res
/pp/bin/i386-win32/rm.exe -f *.s *_ppas.bat
make -C win32
clean
make[7]: Entering directory
`C:/lazarus/fpc/trunk/rtl/win32'
/pp/bin/i386-win32/rm.exe -f
C:/lazarus/fpc/trunk/rtl/units/i386-win32/system.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/uuchar.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/objpas.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/macpas.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/iso7185.ppu C:/l
zarus/fpc/trunk/rtl/units/i386-win32/buildrtl.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/lineinfo.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/lnfodwrf.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/sysinitpas.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/sysinitcyg.ppu C:/lazarus/fpc/trunk/rtl/
nits/i386-win32/sysinitgprof.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/ctypes.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/strings.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/heaptrc.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/matrix.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/windows.pp

C:/lazarus/fpc/trunk/rtl/units/i386-win32/winsock.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/winsock2.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/initc.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/cmem.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/dynlibs.ppu C:/lazarus/fpc/trunk/rtl/units/i
86-win32/signals.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/dos.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/crt.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/objects.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/messages.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/rtlconsts.ppu C:/lazarus/fp
/trunk/rtl/units/i386-win32/sysconst.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/sysutils.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/math.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/types.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/strutils.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/dat
utils.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/varutils.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/variants.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/typinfo.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/fgl.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/classes.ppu C:/lazarus/fpc/trunk/
tl/units/i386-win32/convutils.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/stdconvs.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/cpu.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/mmx.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/charset.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/character.ppu :/lazarus/fpc/trunk/rtl/units/i386-win32/ucomplex.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/getopts.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/winevent.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/sockets.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/printer.ppu C:/lazarus/fpc/trunk/rtl/uni
s/i386-win32/video.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/mouse.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/keyboard.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/fmtbcd.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/winsysut.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/sharemem.ppu C:/laz
rus/fpc/trunk/rtl/units/i386-win32/exeinfo.ppu
C:/lazarus/fpc/trunk/rtl/units/i386-win32/fpintres.ppu C:/lazarus/fpc/trunk/rtl/units/i386-win32/windirs.ppu /pp/bin/i386-win32/rm.exe
-f C:/lazarus/fpc/trunk/rtl/units/i386-win32/math.rst C:/lazarus/fpc/trunk/rtl/units/i386-win32/varutils.rst C:/lazarus/fpc/trunk/rtl/units/i386-win32/typinfo.rst C:/lazarus/fpc/trunk/rtl/units/i386-win32/variants.rst C:/lazarus/fpc/trunk/rtl/units/i386-win32/classes.rst C
/lazarus/fpc/trunk/rtl/units/i386-win32/dateutils.rst C:/lazarus/fpc/trunk/rtl/units/i386-win32/sysconst.rst /pp/bin/i386-win32/rm.exe
-f fpcmade.i386-win32 Package.fpc ppas.sh script.res link.res
/pp/bin/i386-win32/rm.exe -f *.s *_ppas.bat
make[7]: Leaving
directory `C:/lazarus/fpc/trunk/rtl/win32'
make[6]: Leaving directory
`C:/lazarus/fpc/trunk/rtl'
make -C C:/lazarus/fpc/trunk/rtl 'OPT= '
all
make[6]: Entering directory `C:/lazarus/fpc/trunk/rtl' make -C win32
all
make[7]: Entering directory
`C:/lazarus/fpc/trunk/rtl/win32'
C:/pp/bin/i386-win32/ppc386.exe -Ur -Xs
-O2 -n -Fi../inc -Fi../i386 -Fi../win -FE.
-FUC:/lazarus/fpc/trunk/rtl/units/i386-win32 -di386 -dRELEASE -Us -Sg system.pp -Fi../win
generic.inc(2505,13) Fatal: Internal error 8
Fatal:
Compilation aborted
make[7]: *** [system.ppu] Error 1
make[7]: Leaving
directory `C:/lazarus/fpc/trunk/rtl/win32'
make[6]: *** [win32_all]
Error 2
make[6]: Leaving directory `C:/lazarus/fpc/trunk/rtl' make[5]:
*** [rtl] Error 2
make[5]: Leaving directory
`C:/lazarus/fpc/trunk/compiler'
make[4]: *** [next] Error 2
make[4]:
Leaving directory `C:/lazarus/fpc/trunk/compiler'
make[3]: ***
[ppc1.exe] Error 2
make[3]: Leaving directory
`C:/lazarus/fpc/trunk/compiler'
make[2]: *** [cycle] Error 2
make[2]:
Leaving directory `C:/lazarus/fpc/trunk/compiler'
make[1]: ***
[compiler_cycle] Error 2
make[1]: Leaving directory
`C:/lazarus/fpc/trunk'
make: *** [build-stamp.i386-win32] Error 2

In our previous episode, said:

I am trying to update my FPC from SVN, but for some reason I keep on getting a compilation error. The last build was from 21955 (23rd July 2012). See below for the makefile output.

The crucial bit of information, the version of the starting compiler, is missing.

It should be 2.6.0, and nothing else.

The starting compiler is also from SVN (21955).

In our previous episode,

[1]said:

> I am trying to update my FPC

from SVN, but for some reason I keep on getting a compilation error. The last build was from 21955 (23rd July 2012). See below for the makefile output.

The crucial bit of information, the version of the starting

compiler, is

missing. It should be 2.6.0, and nothing else.

2012/10/16 :

The starting compiler is also from SVN (21955). On 16 okt '12, wrote: It should be 2.6.0, and nothing else.

Then the solution is simple, use fpc 2.6.0.

Vincent

In our previous episode, said:

The starting compiler is also from SVN (21955).

[bold][font size=10000][color=red][style=blink]
The starting compiler is only guaranteed to work if it is the last release. And only the last release, 2.6.0.

Anything else can break at any time.
[/style][/color][/font][/bold]

I heard you the first time, don't worry. Just don't clown around so much. It was a perfectly normal reply on your mail. I will do as you proposed.

In our previous

episode, [1]said:

> The starting compiler

is also from SVN (21955).

[bold][font

size=10000][color=red][style=blink]

The starting compiler is only

guaranteed to work if it is the last release.

And only the last

release, 2.6.0.

Anything else can break at any time.

[/style][/color][/font][/bold]

Marco van de Voort wrote

[bold][font size=10000][color=red][style=blink] The starting compiler is only guaranteed.... [snip] [/style][/color][/font][/bold]

hehehe.... It is rather crazy how often this same problem occurs on the mailing list.

Just thinking out loud...
Couldn't there be a check in the build system that if the FPC version is not the latest know released version, the build will immediately terminate with same message your wrote. The build system in Trunk and Fixes branch could be hard-coded to what the correct starting compiler version should be (just like the compile has a constant to say what version it is).

Optional: And if for some "advanced" reason a starting compiler other than the last stable release version must be used, then a --force or something like that parameter could be introduced too.

This will then hopefully reduce (or with some luck totally eliminate) this very popular support question.

G.

In our previous episode, Graeme Geldenhuys said:

And how old the problem is. It was already in the "make cycle faq" I think, the precursor to the buildfaq.

Graeme Geldenhuys wrote

This will then hopefully reduce (or with some luck totally eliminate) this very popular support question.

I work like this.
I try to eliminate questions from the users.
In principle users of my progam only have to plug a USB Stick and the powercable in the computer.

Without go deep in it likely it is possible to implement your suggestion. But that means work...

Rainer Stratmann wrote

But that means work...

And how much waisted time was spend by users "debugging the issue" and by developers answering the same question over and over. As Marco said, this issue has been around for years!

Programmers write code to reduce work, not make more work. :)

Regards,
- Graeme -

Yes, of course. The work will be worthwhile, but someone has to do that work...

Programmers write code to reduce work, not make more work. :)

Recently I read a comment:
http://www.heise.de/developer/news/foren/S-Programmierer-tun-mir-leid/forum-238723/msg-22487244/read/ Translation (hope I do it right): I pity programmers, they will never finish.

Regards, - Graeme -

As the solution doesn't seem to be too difficult which file or files can "we" zoom in on to fix it?

Frank Church wrote

As the solution doesn't seem to be too difficult which file or files can "we" zoom in on to fix it?

Thanks for showing interest in this. I know near zero about Makefiles and Makefile.fpc. I'm still a bit confused with FPC though. Does FPC now use fpmake everywhere? If yes, then why are there still so many Makefiles in FPC Trunk? Quite possibly I just don't understand the use of fpmake I guess.

The idea seems quite simple though. Do a `$compiler -iV` where $compiler is the starting compiler use to compile the FPC source code. If that version doesn't match a known "latest stable compiler version" constant, then report an error and terminate.

Regards,
- Graeme -

Some slack would be desirable: stable is 2.6.0 but there are known issues which are fixed by 2.6.1. Perhaps we need something like "FORCE=1" to allow a minor version bump to be accepted, or "FORCE=1.1" to accept anything up to 2.7.1.

However the thing that's really needed in my opinion is a clear statement for each SVN tag which FPC version should be used for compilation. Ditto for Lazarus, it shouldn't be necessary to delve into the source to find this.

Graeme Geldenhuys wrote

The idea seems quite simple though. Do a `$compiler -iV` where $compiler is the starting compiler use to compile the FPC source code. If that version doesn't match a known "latest stable compiler version" constant, then report an error and terminate.

See and the rest of the thread.

Jonas

ACCEPTEDVERSION="x.x.x" also could be a flexible solution.

However the thing that's really needed in my opinion is a clear statement for each SVN tag which FPC version should be used for compilation. Ditto for Lazarus, it shouldn't be necessary to delve into the source to find this.

Mark Morgan Lloyd wrote

Some slack would be desirable: stable is 2.6.0 but there are known issues which are fixed by 2.6.1.

Nope, the FPC developers made the rules quite clear! Not even the fixes branch is guaranteed to compile FPC Trunk. ONLY the last released FPC is guaranteed. I have even stumbled over this too, where the fixes branch couldn't compile FPC Trunk, but the latest released version could.

The fixes branch is "mislabelled". Contrary to the name, not only fixes get applied to that branch. In recent months, more and more "minor new features" got added to the fixes branch too.

Perhaps we need something like "FORCE=1" to allow a minor version bump to be accepted, or "FORCE=1.1" to accept anything up to 2.7.1.

This is exactly what I mentioned too, but only for very specific cases (though I don't know if such cases exist). Allow a --force or something parameter to allow the developer to use a different starting compiler (thus ignoring the version check), but ONLY if they know what they are doing.

However the thing that's really needed in my opinion is a clear statement for each SVN tag which FPC version should be used for

That will be a ridiculous amount of work. The existing rule of always using the latest released FPC as the starting compiler is good enough.

Regards,
Graeme.

Jonas Maebe wrote

See http://www.mail-archive.com/..../msg25868.html and the rest of the thread.

[embarrassed] Clearly my age is starting to show. :-) How do you find this old messages in any case.

Your concern about cross-compiling could be an exception - FPC version restriction is not applied in such cases. Cross-compiling in by far the less used option. Most people that complain about this issue is simply trying to compile a new FPC version for their current target.

The --force or --ignore-fpc-version option could still help those corner cases, like new platforms where a previous released version did not exist. The developers working on such features should know what they are doing anyway, so fits in with my earlier statement too.

Regards,
- Graeme -

Graeme, I know what policy is. However I'd point out that right now you /need/ 2.6.1 to compile FPC for SPARC due to code generation issues, and there have previously been similar problems with ARM while FP stuff was work-in-progress.

So saying "if it won't compile with stable then sod off" isn't helpful.

Mark, I understand what you mean.

Regardless of the way Graeme put his point, I think having:
- a rough check on latest stable compiler
- a way to force the makefile to override the check for people who need this such as SPARC users)
will lessen the amount of problems significantly

Thanks,
Reinier

I agree, I was only arguing with the dogmaticism of Graeme's assertion.

In our previous episode, Reinier Olislagers said:

http://www.stack.nl/~marcov/toplevelMakefile.fpc.patch

Don't forget to regenerate makefile after applying

It is kept simple on purpose. Only works on toplevel makefile (easy to maintain), only on the toplevel "all" target, the required version is also kept there (toplevel Makefile.fpc as only place).

Mark Morgan Lloyd wrote

So saying "if it won't compile with stable then sod off" isn't helpful.

That's definitely not how I meant for it to sound [the joys of email conversations]. Reinier summed up my thoughts. Default behaviour is to only allow last released FPC version, but there must be an option to force an override or disable the version check (for special cases like you mentioned, or for cross-compiling purposes).

Graeme.

Marco van de Voort wrote

It is kept simple on purpose. Only works on toplevel makefile (easy to maintain), only on the toplevel "all" target, the required version is also kept there (toplevel Makefile.fpc as only place).

Nice, works perfectly here under 64-bit Linux. Tested compiling latest Trunk with FPC 2.6.0 and FPC 2.6.1. I haven't tested cross-compiling, but the OVERRIDEVERSIONCHECK option did work when I used FPC 2.6.1

Hopefully that will be the end of this popular problem.

Graeme.

Marco van de Voort wrote

It is kept simple on purpose. Only works on toplevel makefile (easy to maintain), only on the toplevel "all" target, the required version is also kept there (toplevel Makefile.fpc as only place).

I think it's annoying that you then have to type
OVERRIDEVERSIONCHECK=1 whenever you build a cross-compiler. Even more: it will suggest that building a cross-compiler should also be done starting with the latest release, while in fact it they should be built using a native compiler built from the same svn version. Therefore I don't think think that we can check anything in case of cross-building.

Jonas

Also, maybe the printed message should be more explicit about the fact that using the latest release is the only supported way to bootstrap the compiler, and that OVERRIDEVERSIONCHECK=1 must only be used if you know for a fact that the starting compiler was built from the same sources that you are currently compiler.

Jonas

Jonas Maebe wrote

...whenever you build a cross-compiler. Even more: it will suggest that building a cross-compiler should also be done starting with the latest...

Simply update the error message to say that the version check rules might not apply to newly implemented platforms, or for cross-compiling.

Graeme.

In our previous episode, Jonas Maebe said:

Yes. I already experimented by ifndef CROSSCOMPILE, but that is also when not cross-architecture.

Even more: it will suggest that building a cross-compiler should also be done starting with the latest release, while in fact it they should be built using a native compiler built from the same svn version. Therefore I don't think think that we can check anything in case of cross-building.

Ok. Then it is actually easier, and it is just a matter of disabling it totally for CROSSCOMPILE=1. I expected more complicated rules there.

Another problem I came up with is that the system compares textually, and thus immediately after 2.6.2 release will only allow one of those two (2.6.0 or 2.6.2), not both to allow for a graceperiod of a few weeks.

In our previous episode, Jonas Maebe said:

New text:

D:\repo\fpc>make all
makefile:2717: *** The only supported starting compiler version is 2.6.0. You are trying to build with 2.7.1. If you are absolutely sure that the current compiler is built from the exact same version/revision, you can try to use OVERRIDEVERSIONCHECK=1 to override . Stop.

+ a ifndef crosscompile around the whole version check.

I thought about the 2.6.0<->2.6.2 transition, but it is easy to temporarily wrap another version check around it for a few weeks. More work, but not a problem. (just needs documentation in rel_eng)

2012/10/17 Marco van de Voort :

Alternatively, it could just be a warning. Then if it fails later, the complete output will show the reason.

Then OVERRIDEVERSIONCHECK is not necessary anymore.

Vincent

Vincent Snijders wrote

Alternatively, it could just be a warning. Then if it fails later, the complete output will show the reason.

I disagree. To prevent any strange side-effects (undefined behaviour), the version check should happen as early as possible - before any compiling commences.

Graeme.

In our previous episode, Vincent Snijders said:

True, but I think that will only resolve something in such a low number of cases that it is makes the whole effort negiable.

IOW that defeats the purpose of the check IMHO.

Graeme Geldenhuys hat am 17. Oktober 2012 um 17:05 geschrieben:

I'm compiling fpc trunk with trunk/fixes/release since years. It works more often than not.
I agree with Vincent that a warning would be enough.

Mattias

In our previous episode, Mattias Gaertner said:

True but this check is not added because of FPC and Lazarus developers :-)

Do you manually compile fpc (type make all... etc) or do you use a script?

If you use a script, it is easy to simply add the override define to it (that's what I do)

Marco van de Voort hat am 18. Oktober 2012 um 13:41 geschrieben:

True. Just wondering why adding an error for something that usually works.

Do you manually compile fpc (type make all... etc) or do you use a script?

make all

If you use a script, it is easy to simply add the override define to it (that's what I do)

Mattias

And as the core developers saw today, even that is not clear enough apparently: http://bugs.freepascal.org/view.php?id=23245 (that person even manually edited the makefile and replaced the 2.6.0 with 2.7.1 trying to get around the check).

Jonas

Jonas Maebe hat am 30. Oktober 2012 um 14:44
geschrieben:

Rich Cook
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

Mattias

Mattias Gaertner wrote

Rich Cook "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

Ah, you beat me to it :)

Henry

Mattias Gaertner wrote

> <http://bugs.freepascal.org/view.php?id=23245> (that person even manually > edited the makefile and replaced the 2.6.0 with 2.7.1 trying to get around the > check).

Oh my f#*k!

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

+1000

G.

I really don't like making this comment, but looking at the bug report (and checking the current Makefile)

You try to build with 2.6.1.

That could very easily be misread as "You should try to build with 2.6.1", correct idiomatic English would be "You are trying to build with 2.6.1.", or to rub their nose in it "You are trying to build with 2.6.1, which is not supported.".

The whole purpose of the check was to "rub their nose in it"... but if people try to circumvent the check by editing the Makefile (and not even reading the message correctly to know how to circumvent it correctly) and THEN even raising a bug report about this then what can help?!

Regards,
Sven

I'm definitely not complaining about the check, I agree with it. But to somebody with English as their first/only language "You try" is an imperative, as in "I've cleared the bubbles in the fuel line, you try to start it now.". If we're trying to make it "bloody idiot proof" then the correct form is "you are trying" or "you have tried".

Sensible, and agreed - could be another small step in the race with the Universe :)

Mark Morgan Lloyd wrote

start it now.". If we're trying to make it "bloody idiot proof" then the correct form is "you are trying" or "you have tried".

That make sense. Could Marco or somebody update the grammar in that message?

Regards,
- Graeme -

In our previous episode, Mark Morgan Lloyd said:

r22885 | marco | 2012-10-31 09:09:04 +0100 (Wed, 31 Oct 2012) | 2 lines

* regened toplevel makefile. Some spelling fixes in the versioncheck errormsg were fixed in the Makefile.fpc, but hadn't been propagated to Makefile.