# 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org