> > ... The problem packages are:
> >
> > gcc-multilib which provides:
> > /usr/include/asm
> 
> > For the multiarch configurations, the cross compilers have /usr/include in the search path.
> > Having the symlink there lets the arm cross compiler find the x86 asm headers.

With respect, Matthias, this is flat out wrong.

An unqualified (with architecture) name for a top-level file, directory, or link, says "This is the version of this thing for the default set of tools targeting THIS platform".

In a cross-compiler environment such a thing should never label anything specific to (a subset of the architectures only includes) foreign targets.  (At best it could label something that applies to ALL architectures.)

> >you have to come up with a proper solution, which doesn't involve hacks
> >like [those suggested by T Parys]. 

OK.  Here's one that:
 * without conflicts
 * simultaneously
 * supports both cross-platform and local targets.
 * supports latest/canonical version and back-revision compilation on both cross and local targets (so older, still-live, products can be maintained with the same toolset they were originally built with, if desired), as well as new version 
 * with system administration remaining simple and straightforward
 * all with very little change to the way things are named and packaged now.

The packages are in four layers.  From top to bottom:
 1) meta-packages for the latest/blessed version of the native and optionally for crosses to other architecture
 2) meta-packages for each toolset collection
 3) tool packages specific to an architecture
 4) tool packages common to a group of, or all, architectures

Layers 3) and 4) are the current packages for particular tools and libraries.
  - In 3) the filenames of the main interfaces (tool executable, top-level library directory, etc.) are qualified by both architecture and version (e.g. "arm-linux-gnueabihf-gcc-4.8")
  - In 4) (if any multi-architecture shared packages exist at all) the names are qualified by architecture group (or "-all-", to avoid collisions with layers 1) and 2) ) and version, and are targets of symlinks from 3).

Layer 2) consists of meta-packages that each load a particular architecture-version toolset (but do not make it canonical).  Again it's close to what we have, but all the main interface filenames are still qualified by both architecture and version.

2), 3), and 4) all have qualified filenames where it matters, cleaned up as necessary so they have no conflicts.  All toolsets can be installed simultaneously.  Any of them can be used, even simultaneously, provided the Makefiles of the particular projects explicitly specify the toolset they want to use.

For instance:  The Makefiles of a project might include a project common Makefile that uses an idiom like this:

GNU_INSTALL_ROOT := /opt/gcc-arm-linux-gnueabihf_4%3a4.8.2-1_amd64/
GNU_PREFIX       := gcc-arm-linux-gnueabihf_4%3a4.8.2-1-

CXX              := "$(GNU_INSTALL_ROOT)/bin/$(GNU_PREFIX)g++"
CC               := "$(GNU_INSTALL_ROOT)/bin/$(GNU_PREFIX)gcc"
AS               := "$(GNU_INSTALL_ROOT)/bin/$(GNU_PREFIX)as"
 (etc. for other tools in the set)

Layer 1) declares the default native compiler and (if desired) the preferred version of the cross-compiler for each foreign architecture.
 * For the native compiler the meta-package defines symlinks from the unqualified tool and library names (gcc, g++, as, etc.) to the active version (typically the most recent).  This lets makefiles that don't override the tool and library names (or explicitly declare the defaults) build for the current architecture, as usual.
 * For each cross-architecture toolset the meta-package defines similar links qualified only by architecture.  This lets projects with makefiles that declare a cross-architecture, but don't specify a version, compile using the system administrator's or buildmeiser's choice of compiler (again typically the most recent).
This layer has conflict declarations that keep more than one version from being installed as the default for a given target architecture - but don't conflict between different architectures.

The dependencies drag in all the stuff needed to support any particular layer 1) or 2) instalation.
 * Want the latest toolset for your machine?  Install the layer 1) native meta-package for your architecture.
 * Want to continue supporting a back-rev product in the field with the compiler that built it originally?  Install the layer 2) meta-package for that version (or don't force it to be uninstalled when you migrate to a new version at layer 1) ).
 * Want to cross-compile for some other architecture?  Install the layer 2) meta-package for the version of the toolset you want and/or the layer 1) meta-package for the architecture.  You get no conflicts with your native, or other foreign target, toolsets, and nothing breaks.