[fpc-devel] passing options for the build process.
plugwash at p10link.net
Thu Mar 22 03:32:48 CET 2012
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
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
More information about the fpc-devel