[fpc-pascal] ARM Linux crosscompiler: compiles but... executable gives segmentation fault

Florian Klämpfl florian at freepascal.org
Sat Jan 11 14:03:21 CET 2014


Am 11.01.2014 13:38, schrieb Reinier Olislagers:
> On 11/01/2014 13:32, Florian Klämpfl wrote:
>> Am 11.01.2014 11:14, schrieb Reinier Olislagers:
>>> On 11/01/2014 08:02, Florian Klämpfl wrote:
>>>> Am 10.01.2014 13:27, schrieb Reinier Olislagers:
>>> As I couldn't find any existing docs, I've started this page:
>>> http://wiki.lazarus.freepascal.org/ARM_compiler_options
> 
> First off, thanks again for responding - I do really appreciate solid
> info from people who really know what's going on ;)
> 
>> Hmm, is this really needed? 
> I actually would expect something like that in fpc docs, yes.

Just type fpc -i to see the possible options. If one does not understand
those options, one does not need them :)

> 
>> It clutters only information. I would
>> completly remove the page and collect only the needed  parameters for
>> particular targets at their page because every arm target is different.
> 
> Well, that depends on your point of view - I think it nicely bundles
> information in one spot. Also, there may not be pages for all options
> (ARMv7 for example).

As said, arm targets are very different and every target has its optimal
parameters. E.g. on my NAS running debian 6.0 I build for thumb with
"CROSSOPT=-O4 -Cparmv5te -CIthumb"
and for normal arm with
"CROSSOPT=-O4 -Cparmv5te"
Depending on the distro, one needs different -Fl switches etc. Not to
talk about different OSes.

> People compiling e.g. for Raspberry Pi may not care what all the options
> do but they would if they changed from e.g. the original softfloat
> raspberry debian to raspbian which has hardfloat. Having this kind of
> page IMO helps clarify nicely what the options are.

Yes. But in my opinion then this info should go to the raspi page. I bet
99% of the raspi users don't know what instruction set the raspi needs.
So explaining that -Cparmv6 turns on armv6 code generation does not help
them :)

> 
>>> Please feel free, as usual, to modify with corrections/additions.
>>
>> I see so need for the abi documention. Specifing the abi is normally not
>> needed. It confuses only.
> Well, I wouldn't know. I'm just collecting snippets from all over the
> wiki, forum posts, mailing lists and trying to make sense out of them
> (like the EABIHF versus -dFPC_ARMHF thing). 

Yes, this unneeded -Caeabihf parameter floats around for years already :(

> Sort of trying to demistify
> a cargo cult....
> 
> Of course, I'll be happy to add a note saying that specifying the ABI
> normally is not needed - that'll save some other poor soul from
> wondering whether it's him, the phase of the moon or the wrong ABI
> parameter that caused the compiler to catch fire ;)
> 
> So when /is/ specifying the ABI needed? When supporting a microcontroller?

Simple: if you don't know when it's needed, you don't need it ;)
Seriously: if you want to use an armel compiler to build e.g. for armhf.
But then you probably want to have also some other defines and you
really have to know what you are doing. Or if you have a special armel
setup where you want to use hard float code and abi for speed reasons,
e.g. when having softfloat raspberry debian installed. But these are
special setups, officially not supported.



More information about the fpc-pascal mailing list