Hi,
I got this error when I tried to compile FPC 2.7.1 rev 19546. ------------------------------------------------------------------------------------------------- make[7]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1/rtl/win32' make[6]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1/rtl' make -C W:/md/dev/freepascal/compiler/2.7.1/rtl 'OPT=-gl' all make[6]: Entering directory `W:/md/dev/freepascal/compiler/2.7.1/rtl' make -C win32 all
make[7]: Entering directory `W:/md/dev/freepascal/compiler/2.7.1/rtl/win32' W:/md/dev/freepascal/binutils/2.7.1/i386-win32/gmkdir.exe -p W:/md/dev/freepasca l/compiler/2.7.1/rtl/units/i386-win32
W:/md/dev/freepascal/binutils/ppc386.2_6.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUW:/md/dev/freepascal/compiler/2.7.1/rtl/units/i386-win32 -gl -di386 -dRELEASE -Us -Sg system.pp -Fi../win
text.inc(1955,20) Error: identifier idents no member "CodePage" text.inc(1962,20) Error: identifier idents no member "CodePage" system.pp(714) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted
make[7]: *** [system.ppu] Error 1
make[7]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1/rtl/win32' make[6]: *** [win32_all] Error 2
make[6]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1/rtl' make[5]: *** [rtl] Error 2
make[5]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1/compiler' make[4]: *** [next] Error 2
make[4]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1/compiler' make[3]: *** [ppc1.exe] Error 2
make[3]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1/compiler' make[2]: *** [cycle] Error 2
make[2]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1/compiler' make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory `W:/md/dev/freepascal/compiler/2.7.1' make: *** [build-stamp.i386-win32] Error 2
-------------------------------------------------------------------------------------------------

Marcos Douglas

You are using a 2.5.x/2.6.0RC compiler to start instead of the latest release.

* http://www.freepascal.org/develop.var (second "Note" at the top)
* http://www.stack.nl/~marcov/buildfaq.pdf (section 1.2, the "ppc386" point)
* http://lists.freepascal.org/lists/fpc-devel/2008-April/013541.html
* http://lists.freepascal.org/lists/fpc-devel/2010-February/019321.html
* http://lists.freepascal.org/lists/fpc-devel/2010-July/020891.html
* http://lists.freepascal.org/lists/fpc-devel/2011-September/ 025951.html (mail to you!)
* http://lists.freepascal.org/lists/fpc-devel/2011-September/ 025953.html (mail to you!)
* http://lists.freepascal.org/lists/fpc-devel/2011-September/025984.html
* http://bugs.freepascal.org/view.php?id=20462
*
*

Jonas

Lol. Maybe it's time you create a bot that catches these emails and respond to them automatically :)

Henry

Henry Vermaak wrote

Lol.  Maybe it's time you create a bot that catches these emails and respond to them automatically :)

Maybe the makefile can be amended to check the version number of the FPC being used. If you are trying to compile Trunk, and the FPC version you want to use is not the last known released version, give a error indicating the problem, and refuse to compile Trunk.

This should prevent these type message, which seem to appear quite frequent.

Graeme Geldenhuys wrote

Maybe the makefile can be amended to check the version number of the FPC being used. If you are trying to compile Trunk, and the FPC version you want to use is not the last known released version, give a error indicating the problem, and refuse to compile Trunk.

This would require at least an exception for cross-architecture compiling, because that should always be started with a native compiler compiled from the same code base (a cross-build does not perform a full cycle, which is required for certain kinds compiler of changes to fully propagate in case we have to work around compiler bugs in earlier versions that are triggered by newly added compiler code).

There's also the case where a platform is new and no compiler binary from the previous release exists nor can be created, in which case people often prefer to use that binary as much as possible rather than first cross-compiling one on another platform every time. Probably at least a Makefile flag should be added that can be used to override the check if you think you know what you are doing.

Jonas

Possibly. However:

1) This means (at least) one more place where the latest release version needs to be maintained in the Makefiles.

2) Compiling with a recent trunk version may work under certain circumstances. The current situation is that if it doesn't work, the user should resort to the latest release, but he may use something different as long as it works OK for him. The check in the makefile would disallow using a newer version in all cases which may not be wanted (especially in cases when the last release was not provided for certain platform, you'd need to always start by cross-compilation - imagine a person trying to revive support for some platform doing this multiple times per day)...

Tomas

Well, I just want help... sorry about for your time. It is not gonna happen again to trunk version (maybe you should save this message to show me, in the future).

...

Hm... thinking better you're right. You're the man, the real developer, so... is boring answer these mails, I know, but I really want to help the community! I'm not saying: "Solve my problem!!" you know... I use the stable version. The trunk is for tests and try to help the community.

Best regards.
Marcos Douglas

Ahan... very funny. =|

Marcos Douglas

I'm not "the man, the real developer". And it's great that you use trunk to test. But as I tried to show, it has been mentioned already many times (including in several mails to you) that to compile trunk itself, you *must* always use the latest official release. Any other situation that causes errors is "normal" and the answer will always be "use the latest release".

What is boring is not helping people that have problems, but answering exactly the same question over and over again (although the fact that the same question keeps being asked obviously means that just answering is not sufficient to solve it).

Jonas

Jonas Maebe wrote

This would require at least an exception for cross-architecture compiling,

Ah yes, I forgot about cross compiling.

Probably at least a Makefile flag should be added that can be used to override the check if you think you know what you are doing.

I thought that goes without saying. ;-)

PS:
If you are using Windows, you might considering the product AceText - very handy for anything text related, even those stock replies. It's written by Just-Great-Software. All their products are brilliant - I own a few. And no, I'm not affiliated with is the description of AceText from its website: http://www.acetext.com/

* AceText extends the Windows clipboard, enabling you to copy and paste like never before.
* Take notes, jot down ideas and keep important information at your fingertips.
* Keep common messages and templates to quickly communicate via email or instant messaging.
* Write emails, reports, documents and web sites faster with common text snippets and templates.
* Store and move around blocks of text to easily edit complex documents.
* Keep a digital scrapbook or diary.
* Gather, research and compile information.
* Create and publish a knowledge base or FAQ.
* Instantly find previously saved snippets throughout all your AceText collections.
* And much more! Take advantage of AceText's versatility to speed up and smarten up all your PC activities that involve text.

Couldn't the makefile just have a check for the compilerversion?

It may be bypassed, by some option, if ever required. Only, It might need the additional maintenance, of the "required version" being available in some file, and being updated, when version number changes in trunk (or other branches).

You may want to read the fourth message in this thread.

It may be bypassed, by some option, if ever required.

And also the fifth one.

Only, It might need the additional maintenance, of the "required version" being available in some file, and being updated, when version number changes in trunk (or other branches).

And the sixth one.

And that in a thread about how to prevent the same question from being asked again and again, mainly because people don't read earlier messages or forget about them... :)

Jonas

OK, sorry. You were angry because of my (again) email, I was upset because of your answer... and I wrote what I should not. Well, let's forget this and be friends again.

Anyway, thanks for answer me (again!) ;-)

Best regards,
Marcos Douglas

pleading guilt in all points.

since I learned that I need "the full release installed" for building trunk, I don't follow all the related threads anymore => presenting the danger that when I do pick a msg from a thread like that, I may have missed important stuff.

Jonas Maebe wrote

On 26 Oct 2011, at 15:04, Martin wrote: > It may be bypassed, by some option, if ever required. And also the fifth one.

Well, but isn't that an exception that is valid (and probably will always be valid) for any build? Or maybe I miss something.

To build trunk (or any revision) with a starting compiler, that is itself the same revision => I would expect that to work always?

At least that is my understanding, what happens, in the "make cycle" ? The starting compile is used to build a "current" compiler, which is then used to build itself again?

Martin wrote

To build trunk (or any revision) with a starting compiler, that is itself the same revision => I would expect that to work always?

Yes, but there is no way to encode such an exception in the Makefile without requiring a bunch of svn-related information: a) the svn revision from which the compiler was built has to be added into the compiler binary (that is currently possible, but it's optional) b) the Makefile has to check the svn revision of the current checkout and compare it against the revision encoded in the compiler binary

And then we will start getting mails from people having trouble in case they downloaded a source archive instead of doing an svn checkout.

Jonas

Many of us are in the same position, after all a community is basically a group of people doing their best to help each other.

I've raised several code-generation and debugger bugs over the last few months, which have been fixed promptly by the developers best-suited. /But/ since they're doing it in their own time, it's entirely reasonable that the fixes end up in the trunk version since this is what they've got on their system: if I wanted them merged back into stable or into the next version it's up to me to do it.

If a fix going into trunk rather than into stable forces me to update my own sources or to use a bleeding-edge version of Lazarus then that's my problem.