> > This convention is
> > coded in binutils and gcc packages, as well as in other toolchains.
>
> It is? Do you have some examples?
If you configure (upstream) binutils with --target=<system>, ld will look
for libs in ${prefix}/<system>/lib/
If you configure (upstream) gcc with --target=<system>, compiler will use
${prefix}/<system>/include as default include path - instead
of /usr/include - and add ${prefix}/<system>/lib as library search path
when calling linker.
As for ${prefix}/gcc/<system>/<version> (in pre-3.4 it was
${prefix}/gcc-lib/), it is used for gcc version-specific headers and libs
only; those are put into separate directories to allow several versions of
compiler to be installed under the same prefix.
As for other toolchains, maybe someone from debian-embedded will give some
examples. All toolchains I worked with have been actually gcc-based, so
used gcc directory layout. For example, MontaVista tools actually create a
chroot for target (which is used over NFS), and put libs and headers in
usr/lib/ and usr/include/ directories of that chroot.
> > Isn't it better to make multiarch proposal consistent with de-facto
> > standard of cross-compilation setup?
>
> Have you thought about how such a solution would affect the other
> cases on the webpage?
I could not find anything on that page that will break if lib/<system> is
changed to <system>/lib.
Nikita
Attachment:
pgpM8fso6QFg5.pgp
Description: PGP signature