include/asm missing - change "Suggest" to "Depends" on gcc-multilib

Why do you need /usr/include/asm? /usr/include/<triplet>/asm is already on the path for the compiler; /usr/include/asm is only provided by gcc-multilib in order to support building binaries for an ABI other than the default (e.g., building with gcc -m32 on amd64), where <triplet> for the target doesn't match that for the build system.

This should definitely not be a dependency of gcc or build-essential.

It is however required if you're using the intel compilers, and it is not in any way obvious that gcc-multilib should be installed in order for those to work. If build-essential would depend on gcc-multilib, intel compilers would work out of the box.

build-essential is the set of packages that are implicitly installed for building Debian packages. Intel compilers are sideways to this; I'm afraid this needs to be handled by way of the intel compilers (or packages thereof) being updated to recognize the /usr/include/<triplet> include path by default - because /usr/include/asm is *not* going to be the only bit moved around in /usr/include as a result of multiarch, just the most immediate and prominent one.

I'm not sure what happened here exactly. But the missing asm dir breaks a lot of builds for me, e.g. ufraw for my own system as well. And my thought was also that I need to get just build-essential....

On Mon, May 30, 2011 at 06:15:51PM -0000, D wrote:
> I'm not sure what happened here exactly. But the missing asm dir breaks
> a lot of builds for me, e.g. ufraw for my own system as well. And my
> thought was also that I need to get just build-essential....

You do only need build-essential. If you are using the standard Ubuntu
gcc, it will find headers in this subdirectory without any problems. The
only problems arise when you use either

 - a non-Ubuntu compiler which doesn't know about multiarch paths
 - a build system that inspects the filesystem directly, bypassing the
   compiler's built-in include path.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

This affects the Clang Static Analyzer (scan-build) as well:

In file included from /usr/include/errno.h:36:
In file included from /usr/include/bits/errno.h:25:
/usr/include/linux/errno.h:4:10: fatal error: 'asm/errno.h' file not found
#include <asm/errno.h>
         ^

clang should be made aware of multi-arch as it has a supported package available. Though it is not installed by default. Could it simply depend on gcc-multilib?

no, won't work on armel (which doesn't have gcc-multilib)

clang needs to be aware of multiarch paths, same for llvm

I just hit this problem when I tried to compile vanilla gcc-4.6 from the gcc svn branch.

Two comments:
 (a) installing the multilib package on a non-multilib i686 machine is not a real option
       (why would I install 64bit libs and environment if I don't need them? System hygiene!)
 (b) you can not expect all packages out there to change whatever needs changing to make this work your way

If all that's needed is a symlink, which appears to be the case as I just added one manually, then I suggest to keep that symlink around in the basic build-essential package and everything Just Works (TM).

I can confirm this bug while trying to compile gcc 4.6 on a standard ubuntu installation. Creating the symbolic link /usr/include/asm solves the problem.

It looks this issue was never fixed.
I am now using Ubuntu 16.04, and just got the same issue 'asm/errno.h' file not found!

I see this issue was reported 5 years ago. Why is this never get fixed?