Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

[Jonathan Nieder <jrnieder@gmail.com>]

# affects most development libraries, not just libc
reassign 648889 general
forcemerge 637232 648889
quit

Hi Wolfgang,

Wolfgang Tichy wrote:

> I just tried to comiple some code with the intel compiler and got:
> /usr/include/features.h(323): catastrophic error: could not open source file
> "bits/predefs.h"
>   #include <bits/predefs.h>
>
> The reason seems to be that /usr/include/features.h includes bits/predefs.h
> which does not exist in  /usr/include/ . However, it exists in
> /usr/include/x86_64-linux-gnu/ .

See [1] for some background.

/usr/share/doc/libc6/NEWS.Debian.gz explains:

  Starting with the eglibc package version 2.13-5, the libraries are
  shipped in the multiarch directory /lib/<triplet> instead of the more
  traditional /lib, where <triplet> is the multiarch triplet and can be
  retrieved with 'dpkg-architecture -qDEB_HOST_MULTIARCH'. Similarly the
  includes are now shipped in /usr/include/<triplet> instead of the more
  traditional /usr/include.

  The toolchain in Debian has been updated to cope with that, and most
  build systems should be unaffected. If you are using a non-Debian
  toolchain to build your software and it is not able to cope with
  multiarch, you might try to pass the following option to your
  compiler:

    -B/usr/lib/<triplet> -I/usr/include/<triplet>

I believe the best long-term solution would be to teach the Intel
compiler to use the /usr/{lib,include}/<triplet> directories so it can
find libraries and header files for the target architecture as they
move to the new location.

In the short term, however, you will probably need to configure your
compiler differently (perhaps by adding appropriate flags to your
definition of the CC variable).  Does the Intel compiler support the
-B and -I options?

Thanks for writing,
Jonathan

[1] http://wiki.debian.org/Multiarch