[Bug 1300211] Re: Can't install both gcc-multilib and gcc-arm-linux-gnueabihf

[mcclary]

> > ... 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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-defaults in Ubuntu.
https://bugs.launchpad.net/bugs/1300211

Title:
  Can't install both gcc-multilib and gcc-arm-linux-gnueabihf

Status in gcc-defaults package in Ubuntu:
  Invalid

Bug description:
  Problem is on Ubuntu 14.04.  Earlier versions of Ubuntu don't seem to
  have this issue and the two packages can happily coexist.

  When I run e.g.,
  apt-get install gcc-multilib, it uninstalls the ARM compilers.

  root at rufus-linux:/# apt-get install gcc-multilib 
  Reading package lists... Done
  Building dependency tree       
  Reading state information... Done
  The following packages were automatically installed and are no longer required:
    binutils-arm-linux-gnueabihf cpp-4.8-arm-linux-gnueabihf cpp-arm-linux-gnueabihf gcc-4.8-arm-linux-gnueabihf-base
    libasan0-armhf-cross libatomic1-armhf-cross libc6-armel-armhf-cross libc6-armhf-cross libc6-dev-armel-armhf-cross
    libc6-dev-armhf-cross libgcc-4.8-dev-armhf-cross libgcc1-armhf-cross libgomp1-armhf-cross libsfasan0-armhf-cross
    libsfatomic1-armhf-cross libsfgcc-4.8-dev-armhf-cross libsfgcc1-armhf-cross libsfgomp1-armhf-cross
    libsfstdc++-4.8-dev-armhf-cross libsfstdc++6-armhf-cross libstdc++-4.8-dev-armhf-cross libstdc++6-armhf-cross
    linux-libc-dev-armhf-cross
  Use 'apt-get autoremove' to remove them.
  The following packages will be REMOVED
    g++-4.8-arm-linux-gnueabihf g++-4.8-multilib-arm-linux-gnueabihf g++-arm-linux-gnueabihf
    gcc-4.8-arm-linux-gnueabihf gcc-4.8-multilib-arm-linux-gnueabihf gcc-arm-linux-gnueabihf
  The following NEW packages will be installed
    gcc-multilib
  0 to upgrade, 1 to newly install, 6 to remove and 0 not to upgrade.
  Need to get 0 B/1,024 B of archives.
  After this operation, 31.3 MB disk space will be freed.

  Similarly, when I install the arm compiler, it uninstalls gcc-multilib
  root at rufus-linux:/# apt-get install gcc-arm-linux-gnueabihf
  Reading package lists... Done
  Building dependency tree       
  Reading state information... Done
  The following packages were automatically installed and are no longer required:
    libsfstdc++-4.8-dev-armhf-cross libsfstdc++6-armhf-cross libstdc++-4.8-dev-armhf-cross libstdc++6-armhf-cross
  Use 'apt-get autoremove' to remove them.
  The following extra packages will be installed:
    gcc-4.8-arm-linux-gnueabihf gcc-4.8-multilib-arm-linux-gnueabihf
  Suggested packages:
    gcc-4.8-doc gcc-4.8-locales libgcc1-dbg-armhf-cross libgomp1-dbg-armhf-cross libitm1-dbg-armhf-cross
    libatomic1-dbg-armhf-cross libasan0-dbg-armhf-cross libtsan0-dbg-armhf-cross libbacktrace1-dbg-armhf-cross
    libquadmath-dbg-armhf-cross manpages-dev automake1.9 gdb-arm-linux-gnueabihf gcc-doc
  The following packages will be REMOVED
    gcc-multilib
  The following NEW packages will be installed
    gcc-4.8-arm-linux-gnueabihf gcc-4.8-multilib-arm-linux-gnueabihf gcc-arm-linux-gnueabihf
  0 to upgrade, 3 to newly install, 1 to remove and 0 not to upgrade.
  Need to get 0 B/5,074 kB of archives.
  After this operation, 15.7 MB of additional disk space will be used.

  Note, this is a test ubuntu disk image created using pbuilder.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1300211/+subscriptions