[fpc-devel] Smarter way of generating ARMHF fpc trunk installation?

Thaddy thaddy at thaddy.com
Wed Mar 5 18:21:27 CET 2014

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.


On 5-3-2014 17:06, Jonas Maebe wrote:
> On 03 Mar 2014, at 09:24, Reinier Olislagers wrote:
>> make "FPC=/home/odroid/development/fpcbootstrap/arm-linux-ppcarm"
>> "--directory=/home/odroid/development/fpctrunk/compiler"
> 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
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140305/058d279c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4243 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140305/058d279c/attachment.bin>

More information about the fpc-devel mailing list