Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"
# 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
Reply to: