[fpc-devel] passing options for the build process.

[peter green]

Jonas Maebe wrote:
> The compiler should find the crt*.o files on its own, especially if you create a special compiler binary for the hard float ABI (there is no point in creating a special binary if you still need to separately specify a bunch of additional options to get the correct behaviour). Or are they in distribution-specific directories for the hard float ABI?
debian/ubuntu are introducing (ubuntu have had support for a while, debian have been a bit slower on the uptake) something called multiarch. The idea of multiarch is that one system will be able to have packages from a mix* of architectures installed at the same time. This is not something specific to armhf (though armhf does of course have a multiarch triplet).


As a result of this many libraries (including crt*.o)  are now located 
in /usr/lib/<multiarch triplet*> (or lib/<multiarch triplet>). See 
debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636802 for 
previous discussion of this. Debian currently handles this through an 
entry in the default config file (though the entry they are using right 
now is likelt to be problematic on a multiarch system with both armel 
and armhf since it will match the lib directories for both).

A key thing about the way multiarch works is that libraries that are 
packaged to support multiarch will be located in multiarch directories 
even if the system they are installed on only has packages from one 
architecture installed.

Multiarch is a debian/ubuntu creation. I believe someone is attempting 
to push support to upstream gcc. I'm not aware of any distros outside 
the debian family that are currently using it,

I am quite happy to prepare a patch that adds the multiarch locations 
for each architecture to the hardcoded default search paths if you 
believe that is an appropriate thing to do.

* A multiarch triplet represents an ABI. They are based on GNU triplets 
but not nessacerally identical to them because sometimes one GNU triplet 
can convert multiple ABIs and sometimes there can be more than one GNU 
triplet in use for the same ABI. http://wiki.debian.org/Multiarch/Tuples
** in practice most multiatch systems will probally be combinations like 
i386/amd64 or ppc/ppc64 or maybe armel/armhf but in principle any 
combination is possible as long as you can find a way (e.g. binfmt-misc 
with qemu) to make the biniaries run