Hi,

I just got an FPC 2.7.1 update (r22088) and tried to do a new compile. Yes, I am using the released 2.6.0 as starting compiler. I get the following error in the fpdoc code.

Using Linux 64-bit with FPC 2.6.0 64-bit as starting compiler.

===========================
...snip...
make[3]: Entering directory `/home/graemeg/devel/fpc-2.7.1/src/utils/dxegen' make[3]: Leaving directory `/home/graemeg/devel/fpc-2.7.1/src/utils/dxegen' make -C fpdoc all
make[3]: Entering directory `/home/graemeg/devel/fpc-2.7.1/src/utils/fpdoc' /home/graemeg/devel/fpc-2.7.1/src/compiler/ppcx64 -Ur -Xs -O2 -n -S2h -Fu/home/graemeg/devel/fpc-2.7.1/src/rtl/units/x86_64-linux -Fu/home/graemeg/devel/fpc-2.7.1/src/packages/paszlib/units/x86_64-linux -Fu/home/graemeg/devel/fpc-2.7.1/src/packages/fcl-process/units/x86_64-linux -Fu/home/graemeg/devel/fpc-2.7.1/src/packages/hash/units/x86_64-linux -Fu/home/graemeg/devel/fpc-2.7.1/src/packages/fpmkunit/units/x86_64-linux -Fu/home/graemeg/devel/fpc-2.7.1/src/packages/fcl-base/units/x86_64-linux -Fu/home/graemeg/devel/fpc-2.7.1/src/packages/fcl-xml/units/x86_64-linux -Fu/home/graemeg/devel/fpc-2.7.1/src/packages/fcl-passrc/units/x86_64-linux -Fu/home/graemeg/devel/fpc-2.7.1/src/packages/chm/units/x86_64-linux -FE. -FUunits/x86_64-linux -Cg -dx86_64 -dRELEASE fpdoc.pp dw_html.pp(1908,50) Error: Incompatible type for arg no. 2: Got "Pointer", expected "AnsiString"
dw_html.pp(3562) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
make[3]: *** [fpdoc] Error 1
make[3]: Leaving directory `/home/graemeg/devel/fpc-2.7.1/src/utils/fpdoc' make[2]: *** [fpdoc_all] Error 2
make[2]: Leaving directory `/home/graemeg/devel/fpc-2.7.1/src/utils' make[1]: *** [utils_all] Error 2
make[1]: Leaving directory `/home/graemeg/devel/fpc-2.7.1/src' make: *** [build-stamp.x86_64-linux] Error 2

===========================

Fixed in rev. 22092.

I am working on the fcl-passrc pascal source scanner, updating it and creating test suites along the way. I didn't get around to fpdoc yet.

Michael.

Michael Van Canneyt wrote

Fixed in rev. 22092.

Thanks Michael, it's compiling 100% now.

Michael Van Canneyt wrote

Fixed in rev. 22092.

22097:

Since several versions I get multiple of those:

make -C linux all
make[7]: Entering directory
`/home/mschnell/Downloads/svn/fpc/trunk/rtl/linux' /bin/mkdir -p /home/mschnell/Downloads/svn/fpc/trunk/rtl/units/i386-linux /usr/local/bin/fpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../unix -Fii386 -FE.
-FU/home/mschnell/Downloads/svn/fpc/trunk/rtl/units/i386-linux -di386 -dRELEASE -Us -Sg system.pp
variant.inc(82,10) Error: Illegal type conversion: "Text" to "TextRec" variant.inc(84,15) Error: Constant and CASE types do not match

What compiler should I use to compile ?

-Michael

You must do a "make cycle" in the main or compiler directory, with as a starting compiler version 2.6.0.

Usually, I do a
make cycle PP=ppcx64-2.6.0

Michael.

Michael Van Canneyt wrote

You must do a "make cycle" in the main or compiler directory, with as a starting compiler version 2.6.0.

Never heard of this one =-O
What does it do ?

Usually, I do a make cycle PP=ppcx64-2.6.0

should I PP the compiler to be used to compile fpc ?

Right now, for compiling I do

make clean all FPC=/usr/local/bin/fpc

and

/usr/local/bin/fpc is
Free Pascal Compiler version 2.7.1 [2012/07/16] for i386

Some time ago I used a dedicated (old) version of fpc to compile fpc, but after this did not work any more, I updated my script to use the most recent version I was able to compile.

Is this wrong ? Should I (like in former times) d/l a released version (2.6.0) and install it somewhere in a separate directory ?

Thanks a lot,
-Michael

As is always told in such situation: compiling trunk (2.7.1) or fixes head (2.6.1) is ONLY supported by the last released version of FPC (2.6.0) and a compiler of the exact same revision (mostly for cross compilation). Everything else is not guaranteed to work. The error above is the result you get when compiling trunk from an older trunk version, which is not supported.

Regards,
Sven

Michael Van Canneyt wrote

make cycle PP=ppcx64-2.6.0

I always do...

make clean
<svn update>
make all FPC=<last stable FPC release>

This always seems to work. I assume 'make all' gets translated to a 'make cycle' somehow? Or have I just been lucky for the last 5 years doing it my way?

What's the difference between 'all' and 'cycle' options?

Your commands seem correct to me, but.... ALWAYS, ALWAYS, ALWAYS USE THE LATEST ***RELEASED*** FPC TO COMPILE TRUNK.

You don't need "make cycle" for just compiling the compiler, rtl and packages. "make cycle" in the compiler directory is used internally by a "make all" on the top level source directory to build a new compiler in multiple steps. It's also mostly used by us compiler devs to ensure that the compiler still compiles ;)

As said in my other mail: the only supported way to compile a trunk version is to use the last release which in this case is 2.6.0. Everything else might only work by chance. Also if this should not work some time then this is most likely a bug in trunk which needs to be fixed. The possibility to compile FPC by the last version can be considered more or less an invariant, which must be kept valid at all times by the developers (more or less ;) ).

Regards,
Sven

hi,

"make cycle" is for compiling the compiler itself, to be started in the "compiler" subdirectory. "Cycling" in this context means that the compiler compiles itself a few times, each time with the recently compiled compiler, to make sure that the resulting version has been compiled with the latest version, and all current optimizations and compile settings have been used.

"make (zip)install" compiles everything, i.e. the cycle + packages and optionally gives you a nice single-file archive which can be used to install fpc.

We basically try to guarantee that the current sources are compilable (i.e. make cycle/make (zip)install works) with the latest release compiler. If it does not work, it is a bug.

Starting with a 2.7.1 compiler, while often works, is not officially supported.

most recent version I was able to compile. Is this wrong ? Should I (like in former times) d/l a released version (2.6.0) and install it somewhere in a separate directory ?

You only need the ppcXXX binary. Get it from the bootstrap directory on the ftp server, or extract the ppcXXX binary from a release.

Thomas

Graeme Geldenhuys wrote

ALWAYS, ALWAYS, ALWAYS USE THE LATEST ***RELEASED*** FPC TO COMPILE TRUNK.

I see that does make sense.

Is there a chance to just put the appropriate executable somewhere without doing a real installation ?

Thanks,
-Michael

This is exactly what I did until my rather old installation of the <stable FPC release> was not able any more to compile the sources.

But I just did not know how to get the <last stable FPC release> and install it in some other location than /usr/local/bin/fpc

-Michael

"make cycle" only works in the compiler directory and is used internally by a "make all" to compile a new compiler in the correct way and to ensure that it can compile itself again.

Normal users don't need "make cycle".

Regards,
Sven

Install in a temp location from the tar.gz archive, copy binary to the place of your choice.

Michael.

Thomas Schatzl wrote

"make cycle" is for compiling the compiler itself, to be started in the "compiler" subdirectory.

I see.

I don't see how this should work unless the latest released version is installed anywhere. I guess _this_ is my problem.

After compiling I do

make FPC=`pwd`/compiler/ppc386 install INSTALL_PREFIX=/usr

to install the just compiled version to make it usable with Lazarus

This does work, but i understand that this does not do any compiling.

-Michael

make cycle also gives you the latest compiler binary.

Since the original poster is using a trunk compiler, I assume he also wants the compiler updated, because the RTL compiled with the latest release is useless for the installed trunk compiler: It can only be used for compilation with the latest release compiler.

Michael.

They do when using a trunk compiler. Not if using the released compiler.

Michael.

Correct.

You don't need to specify the compiler here as "install" uses the compiled compiler (AFAIK).

to install the just compiled version to make it usable with Lazarus This does work, but i understand that this does not do any compiling.

AFAIK it does do some compiling... e.g. the fpc utility is compiled in that case.

Regards,
Sven

Michael Van Canneyt wrote

Install in a temp location from the tar.gz archive, copy binary to the place of your choice.

This one for X86 Linux?

http://sourceforge.net/projects/freepascal/files/Linux/2.6.0/fpc-2.6.0.i386-linux.tar/download

I'll give it a try.

Thanks a bunch,
-Michael

The only trunk compiler they could use for compiling a trunk compiler is the compiler that is created for that exact revision. Using an older trunk compiler (even using "make cycle") is not supported and I don't think it's good to encourage people to use an (older) trunk compiler to compile trunk...

Regards,
Sven

Michael Schnell wrote

After compiling I do make FPC=`pwd`/compiler/ppc386 install INSTALL_PREFIX=/usr

'make install' doesn't compile anything, it just copies the already compiled unit and executables in the correct location.

My own FPC usage:
I never install FPC or Lazarus in /usr, I rather install them into my $HOME/devel/ directory. I always have write access there, and if I upgrade my Linux (normally via a brand new install), my /home partition is untouched by the reinstall, and all my development tools and code are instantly available and working. My ~/.fpc.cfg is also setup to handle multiple FPC versions and multiple targets for each version, and I normally have 3 FPC versions installed: latest released (2.6.0), the latest fixes branch (2.6.1) and trunk (2.7.1)

For example, here is my build script for Trunk 64-bit.

---------[start-trunk64]------------------
#!/bin/bash

COMPILER=/home/graemeg/devel/fpc-2.6.0/x86_64-linux/bin/ppcx64

make clean
make all FPMAKEOPT="-T 8" FPC=$COMPILER
make install INSTALL_PREFIX=/home/graemeg/devel/fpc-2.7.1/x86_64-linux/ FPC=$COMPILER

---------------------------------------------

I have similar scripts for Trunk 32-bit, Fixes (32/64 bit) and Fixes x-compiler to 32-bit Windows.

I did not suggest that, on the contrary ?

When using a trunk compiler (that was a given from OP) the only way to update is the following:

# update rtl & compiler to latest trunk.
svn update rtl compiler
# run cycle using latest release.
make cycle PP=latest-release
# now you have latest rtl & compiler ready to install. make install

I have this automated in a script.

If you have only the release compiler, cycle is not needed. Then, you can just recompile the RTL, packages, utils.

Michael.

Michael Van Canneyt wrote on Thu, 16 Aug 2012:

That's incorrect, you never need an explicit "make cycle". Simply do the following in the top level FPC directory:

make distclean
svn up
make FPC=latest-release all -j ncpus FPMAKEOPT="-T ncpus" make install

The top-level "make all" already includes a "make cycle" and will also compile packages and utils

Jonas

Voila, that's even easier...

my own script has several options to disable/enable certain steps, which is why I explicitly separate out the various stages.

The point I was trying to get across, however, is that the above is the only correct way of getting FPC up-to-date for a trunk compiler: you need to cycle (explictly, or implicit using make all)

Michael.

Just checked... no it doesn't. Maybe I was fooled by the UPXing that was taking place in earlier versions when doing "install" ;)

Regards,
Sven

I have had problems before which forced me to start specifying the compiler....admittedly, that was many years back. So since then I have always specified the compiler and never had problems since then.

Jonas Maebe wrote

make FPC=latest-release all -j ncpus FPMAKEOPT="-T ncpus"

Two questions...

1) Is the -j <n> option still needed, now that we moved to fpmake with the -T option? Sven said the -j option isn't usable any more.

2) Does the value passed to -j or -T differ? I know with -j <n> you usually specify the number of cores +1 (this was recommended all over the internet messages I read). The -T in fpmake means threads as far as I understand. So a i7 quad core can handle 8 threads simultaneously. So then in that case I would specify -T 8. Is this correct?

Hi,

The -T only covers what fpmake is processing, i.e. packages. The -j switch is still usable, but won't help a lot because most of the compilation of the other things is not parallelizable on that level.

Actually, the speedup due to use of -T is not much anyway, because the effort for packages are relatively minor to compiling the rtl and compiler six times (during the "cycle" :).

If you compile your sources from a current SSD, it may not have any effect because it typically provides the necessary read/write performance to saturate all worker threads. The reason for specifying the "+1" (or any other magic constant/multiplier) is that without SSD the threads were often waiting for the HDD delivering data to process. Additional threads can do their work during that time.

You can still do that, but the benefit may be small with an SSD, but adding another worker thread may not hurt too much either.

Just test it because gains are dependent on the available hardware. I.e. use tools like "time".

Thomas

Hi,

No, if no FPC or PP option is set, the makefiles always use a compiler executable in the path. This is typically the installed compiler.

I have had problems before which forced me to start specifying the compiler....admittedly, that was many years back. So since then I have always specified the compiler and never had problems since then.

That's why.

Thomas

Graeme Geldenhuys wrote on Thu, 16 Aug 2012:

It doesn't make a difference for the packages directory, because that one uses fpmake. It can make a difference for the RTL directory (it doesn't currently under Linux, but it may in the future).

Those "all over the internet messages" are mostly based on experience from 10-20 years ago with extremely slow hard drives and even slower compilers. The idea is that while one process is waiting for I/O to complete, another process can use the waiting one's share of cpu time to compile something in between. However, since FPC compiles fairly quickly, you'll usually be completely I/O bound anyway if there is in fact an I/O bottleneck, so I doubt it will help much. Just time both scenarios a couple and see which one is faster. I don't think you'll see a statistically significant difference.

There is no semantic difference between the value for the -T and -j parameters (whether the code is executed in a separate thread or in a separate process is completely irrelevant), so just specify the same value for both.

Jonas

In our previous episode, Sven Barth said:

IIRC it used to work if the all and install targets are in the same invocation, but not when separating make into two different calls and the version of the globally installed compiler and the version to install differ. It might also apply to other state (crosscompilation state related), never got to the bottom of that.

Since I routine do this now (passing the compiler in compiler/ to make install), I don't know if it changed.

Probably the version info queried in "make all" gets updated along the way for use after make cycle, and those updates are lost when make is restarted and rebuilt using the compiler in the $PATH

In our previous episode, Sven Barth said:

The compiler is needed for target and version info, see earlier msg. In the past it occasionally did recompile parts, but I haven't seen it in a while.

Hi,

Thomas Schatzl wrote

Actually, the speedup due to use of -T is not much anyway, because the effort for packages are relatively minor to compiling the rtl and compiler six times (during the "cycle" :).

Ever bit helps. :) Thanks for all the information.

At the moment on a i7 3770K with a 500MB/s write speed SSD I can do the whole 'make clean all install' in +- 50seconds. From what I could judge (just by looking at Gnome System Monitor) the packages compile in about 5 seconds with -T 8 specified. So yeah, unfortunately the parallel compilation bit is very small.

Michael Schnell wrote

I'll give it a try.

Using fpc 2.6.0 I could compile the compiler, but now it does not compile Lazarus any more :(.

I'll wait some revisions and retry...

-Michael

Thomas Schatzl wrote

No, if no FPC or PP option is set, the makefiles always use a compiler executable in the path. This is typically the installed compiler.

That would explain in then. The FPC in my path is always the fixes branch compiler - thus not the version recommended when compiling Fixes or Trunk.