Hi,

how does fpc and it's makefiles handle the case of installing a cross compiler on a system having fpc installed?

The target path will differ and I can set that, but how is the config file .fpc.cfg handled?
I'm a bit afraid to mess up the installation not because of fpc but because I'm not really knowing what I'm doing. ;)

Additionally there seems to be no compiler switch for changing the configuration file to use, only -n for ignoring it. Is ist possible to name the .cfg on the command line or how would it be done better?

TIA,
Marc

Marc Santhoff wrote

Additionally there seems to be no compiler switch for changing the configuration file to use, only -n for ignoring it. Is ist possible to name the .cfg on the command line or how would it be done better?

Yes, specify alternative config file using the @ option.  Use in conjunction with -n if you want to exclude the default config file.

In fact you're right, I ovelooked that option. Now that the name ist known:

./ppcrossarm -h | grep @

@<x> Read compiler options from <x> in addition to the default fpc.cfg

That solves most problems for now.

Thanks,
Marc

Il 09/11/2017 02:36, Marc Santhoff ha scritto:

You may edit your fpc.cfg for your different target using an IFDEF/ENDIF pair.

Under Linux I have in my home directory a .fpc.cfg sort of:

#include /etc/fpc.cfg  <--- to get all the defaults #IFDEF CPUARM
---- here all the ARM specific paths and options
#ENDIF

That's the basic idea. All that's between #IFDEF -- #ENDIF is ignored when you're *not* cross-compiling.
All that's between #IFDEF -- #ENDIF overrides the previous settings when you're cross-compiling

Giuliano

I see, so when using fpc for ARM these define is automatically set? And would that be CPUAVR for Atmels chips?

That's the basic idea. All that's between #IFDEF -- #ENDIF is ignored when you're *not* cross-compiling. All that's between #IFDEF -- #ENDIF overrides the previous settings when you're cross-compiling

I have thought about this solution, but did not know the details. Next step will be to generate a default fpc.cfg for the arm cross compiler and merge that into the .fpc.cfg using ifdefs.

Fine, now I know the way. :)

Thanks,
Marc

Il 09/11/2017 22:56, Marc Santhoff ha scritto:

I see, so when using fpc for ARM these define is automatically set?

Yes

And would that be CPUAVR for Atmels chips?

Not sure about that. I never used fpc on Atmel chips. When I'm in doubt about the conditional defines, I either google or take advantage of Lazarus: in project->options I select the target CPU family and the target processor, and then I use "show all options" to see which defines are set.

Giuliano

When I'm in doubt

about the conditional defines, I either google or take advantage of Lazarus: in project->options I select the target CPU family and the target processor, and then I use "show all options" to see which defines are set.

fpc -vc is your friend here.

In our previous episode, Marc Santhoff said:

> #ENDIF I see, so when using fpc for ARM these define is automatically set? And would that be CPUAVR for Atmels chips?

(easiest is to just fpc -va some dummy source and then grep for CPU, or look in the compiler sources (options.pas or systems/ iirc)

You can select a different cpu then the default using fpc -P<architecture>

So if you have a x86 compiled fpc.exe, you can get it to select ppcx64 using fpc -Px86_64 and then e.g. -Twin64 for the target. Then all the relevant directives (CPU64, cpux86_64, win64, mswindows etc) are defined.

(I use windows now because I know those defines by heart, for arm it is the same).

The buildfaq (document section on the FPC site), though somewhat outdated, has some info and examples on this.

Hi again,

(too many sub threads, answering here - thanks to all helpers!)

OK, "$FPC -va | grep CPU" does the trick. If using the ppcrossarm:

./ppcrossarm -va|grep CPU

[0.004] Macro defined: CPUARMEL
[0.004] Macro defined: FPC_CPUCROSSCOMPILING
[0.004] Macro defined: CPUARM
[0.004] Macro defined: CPU32
[0.004] Macro defined: CPUINT32
[0.020] interpreting file option "#IFNDEF CPUI386" [0.020] interpreting file option "#IFNDEF CPUAMD64"

See, an arm compiler. But when using the ppc binary in the same dir it looks different. Here we go:

./ppc -va | grep CPU

[0.008] Macro defined: CPUX86_64
[0.008] Macro defined: CPUAMD64
[0.008] Macro defined: CPU64
[0.008] Macro defined: CPUX64
[0.008] Macro defined: CPUINT64
[0.023] interpreting file option "#IFNDEF CPUI386" [0.023] interpreting file option "#IFNDEF CPUAMD64"

What is that, is ppc used for bootstrapping the cross compiler regardless of any other fpc maybe installed?

Next question is how to get started with lazarus and multiple compilers. How do you do it, using configuration files for lazarus and starting like "lazarus --primary-config-path= <path>"? Or are there other possibilities to try?

Marc

Hi,

Marc Santhoff wrote

What is that, is ppc used for bootstrapping the cross compiler regardless of any other fpc maybe installed?

Yes. First that ppc gets built with the "other FPC" installed. Or you can specify a startup compiler explicitly with FPC= argument to the make. It doesn't even need the rtl or anything, just the "ppcXXX" native compiler.

During the first round it builds this new native compiler + rtl which will be used to bootstrap the actual crosscompiler then.

Charlie

What is ppc?
Where is fpc?

Next question is how to get started with lazarus and multiple compilers. How do you do it, using configuration files for lazarus and starting like "lazarus --primary-config-path= <path>"? Or are there other possibilities to try?

Lazarus supports multiple compilers.
You can either use fpc and switch the target OS and /or processor. Or you can switch the compiler binary: Project / Project Options / Compiler Options / Compiler Command. Replace the default value '$(CompPath)' with the path.

You can use build modes to switch with a mouse click between various sets of compiler options.

Mattias

That happens in the directory of a built but not yet installed cross compiler. The build command following those instructions:

http://j-software.dk/stm32f103.php

was:

gmake clean buildbase installbase CROSSINSTALL=1 CROSSOPT="-XParm-elf-" OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7m PREFIX=../../fpc-arm

IIRC. But actually the path from the PREFIX does not exist. Sth. to investigate or redo for me.

That solution isnt't doable, that would require a compiler for X86_64 and ARM.

Or you can switch the compiler binary: Project / Project Options / Compiler Options / Compiler Command. Replace the default value '$(CompPath)' with the path.

Aha, OK.

You can use build modes to switch with a mouse click between various sets of compiler options.

Beautiful, may take a while to get there, but very handy. :)

Marc

Ok. So I have a newer compiler for the base system built on the fly, nice.

Thanks,
Marc

fpc -Parm calls ppcarm, fpc -Px86_64 calls ppcx64.

Mattias

Am 10.11.2017 18:59 schrieb "Marc Santhoff" :

Ok. So I have a newer compiler for the base system built on the fly, nice.

Not really, because only the compiler and RTL are rebuild for the native system when cross building FPC, all the packages are still missing. So you nevertheless need to do a complete build for your host life you had done for your cross compilation target.

Regards,
Sven

Besides the language - fpc and lazarus are so cool tools!

Thank you,
Marc

In our previous episode, Marc Santhoff said:

> fpc -Parm calls ppcarm, fpc -Px86_64 calls ppcx64. Besides the language - fpc and lazarus are so cool tools!

and fpc -V-1.0 calls ppc386-1.0 etc etc :-)

In our previous episode, Marco van de Voort said:

Whoops, that should be -V1.0 of course. The idea is that you can give releases suffixes, though that is mainly useful for different versions (since then you can each version share a fpc.cfg using version #ifdefs)