Hi, On Mon, 2013-01-21 at 15:42 +0100, Michael Schnell wrote: > On 01/21/2013 03:32 PM, Marco van de Voort wrote: > > I do not understand. There is no such thing as an universal arm package. So > > there is no "the" lazarus debian package for arm. > Of course you are right, but to the user it looks like. I suppose > apt-get and friends is installed with the distribution that of course > does know the system is it meant to run on. > > Now the user just does "apt-get install fpc" or similar and after that > fpc should be usable. > > So the apt-get installation seems to select the correct package for the > flavor. > > What I meant is: the fpc package(es) seem to be provided by the fpc > team. To they provide multiple of them (I only found a single one) here: > > http://packages.debian.org/squeeze/armel/fp-compiler/download -> > http://ftp.de.debian.org/debian/pool/main/f/fpc/fp-compiler_2.4.0-2_armel.deb > > so I supposed it would contain the necessary stuff for all supported > flavors. But maybe I did not look hard enough.
Armel means armv5te softfp for fpc as the name of the package indicates. On newer processors you might use vfpv2, but this requires recompilation of the rtl. Only fpc trunk supports armhf. Any precompiled package on the internet is likely to be armel/softfp. There is a separate package for arm-linux-armhf on the ftp at the moment (ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-armhf vs. ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-armel). Note that if you use default installation paths, one will overwrite files from the other. Short story: make sure to install and use the correct compiler. Long story: The armel/armhf distinction is made by linux user space. The kernel is oblivious to that, i.e. armel statically linked binaries run on armhf user space too. You can use an *armel fpc* trunk compiler on armhf systems to generate *armhf* binaries *if* you make sure that the correct ppu's are used. And you pass the correct options to generate armhf code. You can bootstrap an armhf compiler with the armel compiler. There may be issues with the kernel regarding emulation of some obsolete instructions though. armhf mandates armv7 processors, but for fpc, armel is compiled for the armv5te processors with softfp support. This means that an armel binary compiled with fpc will e.g. use the obsolete "swp" instruction that is emulated by the kernel. However if you don't compile the kernel with emulation for the swp instruction turned on, any (fpc) executable that uses it will crash. Additionally, what may confuse the situation further, at least on debian you can install both armel and armhf libraries side-by-side in a multiarch (like x86/amd64 on intel) configuration. I do not know how other distros handle this. I assume most of them only support armhf - so when compiling for them on them, the armhf trunk compiler may be preferable. I do not know what is used/installed on raspbian - since it is debian it will likely use the multiarch solution and its binaries are armel. Another side note: armel and armhf indicate how floating point values are passed. Armel means that all floating point values are passed in integer registers always, armhf means that fp values are generally passed in floating point registers. The softfp/vfpv2 distinction for armel indicates how the fp operations are performed. Softfp means that all fp operations are performed by software, vfpv2 means that fp operations are performed by the hardware. Although fp values are still passed in integer registers, they're copied to fp registers before performing the operation. From an ABI point of view softfp and vfpv2 are compatible. However, vfpv2 executables will crash if run on a processor not having vfpv2 hardware. You're on your own selecting the correct code path. There is no 2.6.x armhf compiler. There are no plans to backport these changes afaik. Thomas _______________________________________________ fpc-devel maillist - email@example.com http://lists.freepascal.org/mailman/listinfo/fpc-devel