fpcup, an FPC/Lazarus build/installation/update program uses the following steps on ARMHF Linux (e.g. raspbian, odroid):

1. Get FPC stable (2.6.2 currently) ARM bootstrap compiler binary This compiler cannot directly build ARMHF FPC trunk.

2. Use the compiler to build a regular ARM fpc trunk compiler ("the intermediate bootstrap" compiler... sorry, not that good at naming :) )

make "FPC=/home/odroid/development/fpcbootstrap/arm-linux-ppcarm" "--directory=/home/odroid/development/fpctrunk/compiler" "CROSSOPT=-dFPC_ARMHF -Cparmv7a -CaEABIHF -CfVFPv3" "OPT=-dFPC_ARMHF" "OS_TARGET=linux" "CPU_TARGET=arm" "OVERRIDEVERSIONCHECK=1" "cycle"

3. Use the generated compiler to build regular ARMHF FPC+RTL etc, as well as Lazarus.

Would there be a smarter/shorter way of doing this?

Thanks,
Reinier

Reinier Olislagers wrote

fpcup, an FPC/Lazarus build/installation/update program uses the following steps on ARMHF Linux (e.g. raspbian, odroid):

[snip]

Would there be a smarter/shorter way of doing this?

No.

Jonas

Thanks, Jonas ;)

Could the first part(s) be packaged into a small Free Pascal distribution, like the 3 zips on this page?
www.CtrlTerm.com

No, because you have to redo step 2 every single time you update your sources.

Jonas

No. Compiler and source revisions must match.

I'm not suggesting that the source be put into the zip. But could the other tools be put into a zip so I could download a small zip on my Raspberry Pi and easily follow a few directions to compile a new ARMHF FPC+RTL?

I'm also interested in doing something similar for Android.

The point is that the tools change every time a new revision is committed to svn, other than the initial 2.6.2 compiler (which is already available separately).

Jonas

See the lines I started my original post with...
See also
http://wiki.lazarus.freepascal.org/fpcup
specifics about Linux ARMHF (on Odroid, should also apply to other devices) http://wiki.lazarus.freepascal.org/Odroid

Thanks for the links! I need to study fpcup more.

It might be nice to see how simple I can make the process of compiling www.CtrlTerm.com for ARMHF (using fpcup). I'm really trying to avoid crosscompiling. It is good for a full-time programmer, but I'm trying to find the most simple ways to get people started.

OOI in what way does it fail?

Can't remember. Probably ARMHF support was introduced in trunk. There are mailing list messages (either fpc-devel or fpc-pascal) discussing this though..

I have a fresh baked zipinstall (tar.gz, not a deb) for the Raspberry Pi straight from my build farm every morning if you want... But even that is not guaranteed to work every time, since it is trunk.

But anyway, let me know

Thaddy
thaddy[whatever belongs here] thaddy[dot] com

Basically it -2.6.X - doesn't accept the proper options you need. There is a workaround:
Bootstrap with 2.6.2, build a trunk crosscompiler, Then bootstrap immediately again with the trunk compiler with OVERRIDEVERSIONCHECK=1.
The latter will accept the proper options, which are minimally: CROSSOPT="-dFPC_ARMHF -CfVFPV2 -CpARMV6 -CaEABIHF" This works but is not in ANY way supported.

Reinier Olislagers wrote

make "FPC=/home/odroid/development/fpcbootstrap/arm-linux-ppcarm" "--directory=/home/odroid/development/fpctrunk/compiler" "CROSSOPT=-dFPC_ARMHF -Cparmv7a -CaEABIHF -CfVFPv3" "OPT=-dFPC_ARMHF" "OS_TARGET=linux" "CPU_TARGET=arm" "OVERRIDEVERSIONCHECK=1" "cycle"

I just noticed that you are adding -dFPC_ARMH also to CROSSOPT. That does not do anything and can be removed. In combination with your remark at http://wiki.lazarus.freepascal.org/ARM_compiler_options that "e.g. adding -dFPC_ARMHF when compiling a program will not change anything" and the last post of Thaddy also talking about CROSSOPT, there seems to a lot of confusion about what this means. It's nevertheless very simple:
* the -dXXX command line parameter simply tells the compiler to define symbol "XXX" as if there were a {$define XXX} at the top of every compiled source file. By definition this does not (and cannot) affect code generation. Regarding the statement on the wiki: it's like saying that adding "-vl" will not change anything regarding the code generation; it's not wrong, but it shouldn't be said either because it suggests that under some circumstances these parameters actually could change something (for the pedantic nitpickers: -dXXX could change something if fpc.cfg contains an "#ifdef XXX" statements, but that's not relevant here).
* the compiler contains a bunch of {$ifdef FPC_ARMHF} source blocks. When these are enabled and you compile an ARM compiler, then the resulting compiler will generate ARM hardfloat ABI code. Adding - dFPC_ARMHF to OPT means that this parameter will be used while compiling the compiler (both cross and native), and hence the compiled ARM compilers (both cross and native) will generate ARM hardfloat ABI code
* adding a parameter to CROSSOPT means that it is only specified when compiling code using a generated cross-compiler. So if you were to add -dFPC_ARMHF to CROSSOPT and not to OPT, then you would first build an ARM cross-compiler that generate softfp ABI code, and subsequently the makefiles would build a native ARM compiler that itself uses the softfp ABI, but which generates hardfloat ABI code. It seems extremely unlikely that you would deliberately want your cross-compiler and native compiler to generate different code.
* Adding -dFPC_ARMHF both to OPT and CROSSOPT means that -dFPC_ARMHF will be passed once while building the cross-compiler and twice while building the native compiler. Again, this is not wrong, but it shouldn't be done because it suggests that under some circumstances - dFPC_ARMHF should be part of CROSSOPT.

Jonas

Well, call me a monkey or an ape, but if you leave it out, you get an EABI version of the compiler and EABIHF is missing. Whatever you do, bootstrapped from 2.6.2.
On both linux and windows you only seem to obtain an EABIHF capable cross compiler if -dFPC_ARMHF is included in both OPT and CROSSOPT and bootstrap with trunk.

Try it.

Your explanation is both logical and theoretically correct, but QED shows otherwise for about the last 10 months.
But I will look at my build scripts anyway. They produce the desired results, though: EABIHF crosscompilers from windows and linux i386.

Thaddy

[snip]

Well, call me a monkey or an ape, but if you leave it out, you get an EABI version of the compiler and EABIHF is missing. Whatever you do, bootstrapped from 2.6.2. On both linux and windows you only seem to obtain an EABIHF capable cross compiler if -dFPC_ARMHF is included in both OPT and CROSSOPT and bootstrap with trunk. Try it.

Starting with a plain i386 2.6.2 and building trunk on Linux with

make FPC=ppf8 OPT="-dFPC_ARMHF" CPU_TARGET=arm CROSSOPT="-Cparmv7a -CfVFPv3" CROSSBINDIR="/home/jmaebe/diablo/toolchains/armv7-gcc-481-binutils-222-eglibc-217-hard/bin" BINUTILSPREFIX="arm-linux-gnueabi-" all -j 8 FPMAKEOPT="-T 8"

The resulting "ppcarm -i" output:

$ ./ppcarm -i
Free Pascal Compiler version 2.7.1

Compiler Date : 2014/03/05
Compiler CPU Target: arm

Supported targets:
Linux for ARMHF
WinCE for ARM
GameBoy Advance
PalmOS
Nintendo DS
Embedded
Symbian OS for ARM
Darwin for ARM
Android for ARMEL
...
Supported ABI targets:
DEFAULT
EABIHF
...

Similarly, the cross-compiler also shows that it generates ARMHF code. Note that the above procedure is not really advised, and it's better to first build a native trunk compiler and only then a compiler for another architecture with this first one. But it most definitely results in an ARMHF compiler.

Jonas

Thaddy wrote

The latter will accept the proper options, which are minimally: CROSSOPT="-dFPC_ARMHF -CfVFPV2 -CpARMV6 -CaEABIHF"

You should not need -CaEABIHF. A compiler build with -dFPC_ARMHF should automatically use the hard float ABI (and a few other related settings).

I think all the other options you have specified should be accepted by 2.6.x