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

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1300211/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

this is intended. The gcc-multilib package contains the /usr/include/asm symlink which breaks the search paths for cross compilers.

I don't think this is true. The problem packages are:

gcc-multilib which provides:
/usr/include/asm
/usr/share/doc/gcc-multilib

And the following 3 arm packages:
gcc-4.8-arm-linux-gnueabihf which provides
/usr/bin/arm-linux-gnueabihf-gcc-4.8
/usr/bin/arm-linux-gnueabihf-gcc-ar-4.8
/usr/bin/arm-linux-gnueabihf-gcc-nm-4.8
/usr/bin/arm-linux-gnueabihf-gcc-ranlib-4.8
/usr/bin/arm-linux-gnueabihf-gcov-4.8
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/collect2
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/libgomp.spec
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/lto-wrapper
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/lto1
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf-base/NEWS.gz
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf-base/NEWS.html
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf-base/README.Bugs
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf-base/README.ssp
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf-base/changelog.gz
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf-base/changelog.linaro.gz
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf-base/gcc/changelog.gz
/usr/share/doc/gcc-4.8-arm-linux-gnueabihf-base/gomp/changelog.gz
/usr/share/man/man1/arm-linux-gnueabihf-gcc-4.8.1.gz
/usr/share/man/man1/arm-linux-gnueabihf-gcc-ar-4.8.1.gz
/usr/share/man/man1/arm-linux-gnueabihf-gcc-nm-4.8.1.gz
/usr/share/man/man1/arm-linux-gnueabihf-gcc-ranlib-4.8.1.gz
/usr/share/man/man1/arm-linux-gnueabihf-gcov-4.8.1.gz

gcc-4.8-multilib-arm-linux-gnueabihf which provides:
/usr/share/doc/gcc-4.8-multilib-arm-linux-gnueabihf

and gcc-arm-linux-gnueabihf which provides:
/usr/bin/arm-linux-gnueabihf-gcc
/usr/bin/arm-linux-gnueabihf-gcov
/usr/share/doc/gcc-arm-linux-gnueabihf
/usr/share/man/man1/arm-linux-gnueabihf-gcc.1.gz
/usr/share/man/man1/arm-linux-gnueabihf-gcov.1.gz

All those file lists are generated by apt-file

Also confirmed the above by running the following sequence of commands:
   38 cd /
   39 apt-get remove gcc-multilib gcc-4.8-arm-linux-gnueabihf gcc-4.8-multilib-arm-linux-gnueabihf gcc-arm-linux-gnueabihf
   40 find . -type f > neither
   41 apt-get install gcc-multilib
   42 find . -type f > i386
   43 apt-get remove gcc-multilib gcc-4.8-arm-linux-gnueabihf gcc-4.8-multilib-arm-linux-gnueabihf gcc-arm-linux-gnueabihf
   45 apt-get install gcc-arm-linux-gnueabihf
   46 find . -type f > arm
   48 diff neither i386
   49 diff neither arm
The output of "diff neither i386" and "diff neither arm" contain no overlaps.

Do you mind reassessing this?

Cheers,

rufus

Re-opening based on comment #3

there is nothing enlightening in comment #3

A workaround for me was to create the symbolic link from
/usr/local/include/asm to /usr/include/x86_64-linux-gnu/asm
instead of (as supplied by gcc-multilib
/usr/include/asm to /usr/include/x86_64-linux-gnu/asm

If this will be the default the packages won't conflict as arm-gcc does not look in /usr/local/include

I don't see why this is being marked as invalid. For doing cross platform development being able to produce 32 and 64 bit on x86 and arm are needed.

If the work around is just a matter of symlinks then sure this can be fixed?

> I don't think this is true. 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.

Quite frankly, Canonical are being rather pig-headed about this one. Just install the Linaro compilers from here and you are good to go:
https://www.linaro.org/downloads/

> Quite frankly, Canonical are being rather pig-headed about this one.

please respect the code of conduct:
http://www.ubuntu.com/about/about-ubuntu/conduct

Just installing other cross compilers while keeping the wrong asm headers in the search path doesn't solve the problem.

I see this problem as well. I need gcc-multilib for some proprietary software and arm64 gcc for my project. The fact that Ubuntu does not allow to install these 2 packages is rather annoying.

For me it sounds like a bug with packaging. Other distros (like Linux Arch) allow to install both packages without any problem.

On 15.10.2015 20:46, Anatol Pomozov wrote:
> I see this problem as well. I need gcc-multilib for some proprietary
> software and arm64 gcc for my project. The fact that Ubuntu does not
> allow to install these 2 packages is rather annoying.
>
> For me it sounds like a bug with packaging. Other distros (like Linux
> Arch) allow to install both packages without any problem.

Other distros are unlikely to have /usr/include in the default search path for
their cross compilers. Ubuntu does have this included to support the MultiArch
cross builds.

I would need this too. Being able to compile for x86_64 and armhf at the same time should be possible.

Any idea how to solve this?

But _why_ does gcc-multilib create that link?

gcc-multilib is a meta-package. None of the components that actually do anything depend on it. If I remove it and keep just the versioned packages (gcc-5-multilib, g++-5-multilib – or just the appropriate :i386 libraries), gcc/g++ still compile with both -m32 and -m64 just fine and cross-compilers can be installed too and pass a smoke-test.

So this is an obvious workaround. gcc-multilib is not needed for anything, gcc-5-multilib (and g++/gobj/gobj++-5-multilib) will pull in everything that is needed for -m32 and -m64. The only downside is that now the switch to -6- will have to be made manually when it hits appropriate release.

But why, then, does the link exist in the first place?

Perhaps the symlink at /usr/include/asm is better suited elsewhere?

The cpp include path for i386 (-m32 flag), is as follows:

foo ~ $ gcc -m32 -Wp,-v test.c
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.

And for the armhf toolchain ...

foo ~ $ arm-linux-gnueabihf-gcc -Wp,-v test.c
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory "/usr/include/arm-linux-gnueabihf"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/include
 /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/include-fixed
 /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/include
 /usr/include

Wouldn't it be better to allow gcc to find i386 specific asm defines in /usr/include/i386-linux-gnu/asm?

# rm -f /usr/include/asm
# ln -s x86_64-linux-gnu /usr/include/i386-linux-gnu
# ln -s x86_64-linux-gnu /usr/include/x86_64-linux-gnux32

There. Both -m32 and -mx32 flags will work fine. You can have cross compilers installed at the same time. And to boot, no potential for cross-contamination between platform specific macros.

Hopefully, we can agree that a symlink at /usr/include/asm is universally wrong? You can't have platform specific defines in a common include directory for all gcc targets? Maybe we can file a bug against gcc-multilib, and move on?

On 06.04.2016 19:47, T Parys wrote:
> Perhaps the symlink at /usr/include/asm is better suited elsewhere?
>
> The cpp include path for i386 (-m32 flag), is as follows:
>
> foo ~ $ gcc -m32 -Wp,-v test.c
> ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
> ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc/x86_64-linux-gnu/4.8/include
> /usr/local/include
> /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
> /usr/include/i386-linux-gnu
> /usr/include
> End of search list.
>
> And for the armhf toolchain ...
>
> foo ~ $ arm-linux-gnueabihf-gcc -Wp,-v test.c
> ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
> ignoring nonexistent directory "/usr/include/arm-linux-gnueabihf"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/include
> /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/include-fixed
> /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/include
> /usr/include
>
> Wouldn't it be better to allow gcc to find i386 specific asm defines in
> /usr/include/i386-linux-gnu/asm?
>
> # rm -f /usr/include/asm
> # ln -s x86_64-linux-gnu /usr/include/i386-linux-gnu
> # ln -s x86_64-linux-gnu /usr/include/x86_64-linux-gnux32
>
> There. Both -m32 and -mx32 flags will work fine. You can have cross
> compilers installed at the same time. And to boot, no potential for
> cross-contamination between platform specific macros.

no this is plain wrong. The headers are different.

>
> Hopefully, we can agree that a symlink at /usr/include/asm is
> universally wrong? You can't have platform specific defines in a common
> include directory for all gcc targets? Maybe we can file a bug against
> gcc-multilib, and move on?

you have to come up with a proper solution, which doesn't involve hacks like
these. Otoh, I don't understand why you would need gcc-multilib and other cross
compilers at the same time.

Matthias: "Otoh, I don't understand why you would need gcc-multilib and other cross compilers at the same time."

Not to be a smart-alec, but... so that we can compile for x86_32, x86_64, and ARM on the same system.

I've just run into this as well while updating build servers from 12.x to 15.x. Is there another way to install all 3 toolchains simultaneously, without including gcc-multilib?

Right now i'm trying Jans method in comment #14, however I'd prefer a method that didn't require manual upgrades.

This was the entire reason we switched to Ubuntu - the strong cross-compiler support.

Another "me too".

My development evironment requires me to compile code for ARM32, ARM64, x86-32 and x86-64. How can this be supported?

this is a bug tracker, not a fan boy forum. If you need incoherent cross build environments including setups involving both multilib and multiarch, then don't install gcc-multilib, but provide the correct include paths on your own. Or use chroots if you don't need these archs for the same project. However the link

$ ls -l /usr/include/asm
lrwxrwxrwx 1 root root 20 Feb 11 09:47 /usr/include/asm -> x86_64-linux-gnu/asm

is *wrong* for every cross compiler, therefore the conflict. Feel free to provide patches for glibc and gcc to avoid having this symlink at all, and have libc6-dev-i386 install into a location which is *only* read by gcc -m32, *and* which doesn't conflict with libc-dev:i386 or libc6-dev:amd64.

Maybe this will provide clues to the problem.
USING ubuntu 16.04
I couldn't install both cpp-arm-linux-gnueabihf and gcc-4.8-multilib-arm-linux-gnueabihf. I also see other errors.
After following a chain of can't installs I got to binutils which wanted a version which was conflicting with what was installed. Sooo, I'm sure there is a better way but here's what I did:

apt-get remove binutils (That scared me, so I copied all the removed packages)
apt-get install binutils
both packages installed afterwards.
(re-installed all the removed packages that cared to install)
successfully compiled hello.c for arm and ran on parallella. Woo Hoo!

grog, this does not work for me on 16.04.

# apt remove binutils
[...]
The following packages will be REMOVED:
  binutils binutils-arm-linux-gnueabi build-essential clang clang-3.8 dpkg-dev
  g++ g++-5 g++-5-multilib g++-multilib gcc gcc-5 gcc-5-multilib gcc-multilib
  lcov
0 upgraded, 0 newly installed, 15 to remove and 9 not upgraded.
After this operation, 157 MB disk space will be freed.
Do you want to continue? [Y/n] Y
[...]
# apt install gcc-arm-linux-gnueabi gcc-multilib
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gcc-arm-linux-gnueabi : Depends: gcc-5-arm-linux-gnueabi (>= 5.3.1-3~)
E: Unable to correct problems, you have held broken packages.

If I understood these comments correctly, the proper workaround is to remove gcc-multilib and create symlinks manually?

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

Please see my post #23, stating why this bug is, in my opinion, valid and (as requested) proposing a solution.

mcclary states that having /usr/include in the header search path doesn't prevent the inclusion of wrong header files. He then describes a system how to layout files to install multiple native and cross compilers, and how to select defaults. He doesn't talk about the include paths for these setups at all, therefore not addressing the problem that the cross compilers pick up the wrong header files.

Status changed to 'Confirmed' because the bug affects multiple users.

I can confirm that this bug appears in Debian testing too.

One (working ?) alternative we've successfully used here to workaround this weird game of whack-a-mole is to stop relying on gcc-multilib, and start using :i386 versions of packages. So for instance, we would install for example the following list of packages on an amd64 machine:

build-essential g++-aarch64-linux-gnu g++-arm-linux-gnueabihf libc6-dev:i386 libstdc++-7-dev:i386

granted the following has been run beforehand:

dpkg --add-architecture i386

I have faced the issue trying to cross-compile qt webengine using arm-linux-gnueabihf-.
during the build process there is an attempt to build a tool for build machine with `-m32` flag which is failed due to missing `/usr/include/asm/`.

This is what worked for me, to build x86_32, x86_64, ARM and ARM64 UEFI drivers from a single Ubuntu 20.04 platform (which is actually an AppVeyor build environment):

sudo update-alternatives --remove-all gcc
sudo update-alternatives --remove-all g++
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 90 --slave /usr/bin/g++ g++ /usr/bin/g++-9
sudo -E apt-get install -y gcc-9-multilib gcc-9-aarch64-linux-gnu gcc-9-arm-linux-gnueabi
sudo ln -s /usr/include/x86_64-linux-gnu/asm/ /usr/local/include/asm
sudo ln -s /usr/bin/aarch64-linux-gnu-gcc-9 /usr/bin/aarch64-linux-gnu-gcc
sudo ln -s /usr/bin/aarch64-linux-gnu-gcc-ar-9 /usr/bin/aarch64-linux-gnu-gcc-ar
sudo ln -s /usr/bin/arm-linux-gnueabi-gcc-9 /usr/bin/arm-linux-gnueabi-gcc
sudo ln -s /usr/bin/arm-linux-gnueabi-gcc-ar-9 /usr/bin/arm-linux-gnueabi-gcc-ar

If you are interested, you can find the AppVeyor build log, that demonstrates how all 4 versions of gcc were properly invoked, at https://ci.appveyor.com/project/pbatard/ntfs-3g/builds/38316398?fullLog=true

Note that this is a real-life scenario, where some developers actually need to produce UEFI executables, for all supported UEFI archs, in one go. As such, it would really be a lot nicer if a 'gcc-multilib gcc-aarch64-linux-gnu gcc-arm-linux-gnueabi' configuration was supported without having to resort to applying workarounds.

Can someone please explain why /usr/include/asm is needed? It seems to me neither gcc -m32 nor gcc -m64 use it (both finding the ones in /usr/include/i386-linux-gnu and /usr/include/x86_64-linux-gnu instead).

arm-linux-gnueabihf-gcc finds it which is not correct, but can be fixed easily enough by sym-linking /usr/include/arm-linux-gnueabihf to /usr/arm-linux-gnueabihf/include.

From what I can see, the only things ever finding /usr/include/asm are things which should definitely not be using it (cross compilers). If that is correct, removing that symlink from gcc-multilib should not break anything that's not already broken. And with it removed, the conflicts would no longer be necessary.

What am I missing?

Actually, I was wrong about arm-linux-gnueabihf-gcc! It *also* doesn't find /usr/include/asm, instead correctly finding /usr/arm-linux-gnueabihf/include/asm!

So actually, as far as I can tell *nothing* uses /usr/include/asm.

I'm affected by this as well as I can't run Xilinx (Canonical's partner) PetaLinux tools if I want keep cross compilers to build Debian packages for ARM64 target on Xilinx chip. It's hilarious that after so many years this problem exists, cannot be repaired.