Bug#855222: clang-4.0 has wrong C++ include search path order

Jason Rhinelander jason at imaginary.ca
Wed Feb 15 16:48:03 UTC 2017


Package: clang-4.0
Version: 1:4.0~+rc2-1
Severity: normal

Dear Maintainer,

clang-4.0 appears to have a search path order for includes that causes problems
with compilation with libc++ when trying to load stl headers; here's an example
that fails:

$ cat test.cpp
#include <limits>
int main() { return 0; }
$ clang++-3.9 -stdlib=libc++ test.cpp
$ clang++-4.0 -stdlib=libc++ test.cpp
In file included from test.cpp:1:
In file included from /usr/include/c++/v1/limits:110:
In file included from /usr/include/c++/v1/type_traits:387:
/usr/include/c++/v1/cstddef:43:15: fatal error: 'stddef.h' file not found
#include_next <stddef.h>
              ^~~~~~~~~~
1 error generated.


The problem seems to be that, in clang-4.0, clang's include path is injected
before the standard library search path:

$ clang-4.0 -x c++ -stdlib=libc++ -v -E -
...
#include <...> search starts here:
 /usr/include/clang/4.0.0/include
 /usr/include/c++/v1
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include

This isn't specific to libc++: without the -stdlib=libc++ the second line is
replaced with three stdlibc++ include paths, but still show up after the clang
include path.  This doesn't seem to cause problems for stdlibc++, but still
seems incorrect.

In clang-3.9, clang's include path comes after the c++ library:

$ clang-3.9 -x c++ -stdlib=libc++ -v -E -
...
#include <...> search starts here:
 /usr/include/c++/v1
 /usr/local/include
 /usr/lib/llvm-3.9/bin/../lib/clang/3.9.1/include
 /usr/include/x86_64-linux-gnu
 /usr/include


This breaks libc++ under clang-4.0 because it uses `#include_next <stddef.h>`
to get at the compiler's stddef.h, which won't work with the paths in the wrong
order.


Other things I tried:

- I built and installed upstream libc++ 4.0 instead of the debian-packaged
libc++ 3.9.1: same error (unsurprisingly).
- I tried the clang-4.0 snapshot from http://apt.llvm.org/, which exhibits
exactly the same behaviour.
- I built clang and libc++ from the upstream llvm 4.0 branch: it works fine.
The search path for this clang is:
 /usr/local/bin/../include/c++/v1
 /usr/local/include
 /usr/local/bin/../lib/clang/4.0.0/include
 /usr/include/x86_64-linux-gnu
 /usr/include

i.e. the clang include is after the C++ library, where it belongs.



-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-rc6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clang-4.0 depends on:
ii  binutils                 2.27.90.20170205-1
ii  libc6                    2.24-9
ii  libc6-dev                2.24-9
ii  libclang-common-4.0-dev  1:4.0~+rc2-1
ii  libclang1-4.0            1:4.0~+rc2-1
ii  libgcc-6-dev             6.3.0-6
ii  libgcc1                  1:6.3.0-6
ii  libjsoncpp1              1.7.4-3
ii  libllvm4.0               1:4.0~+rc2-1
ii  libobjc-6-dev            6.3.0-6
ii  libstdc++-6-dev          6.3.0-6
ii  libstdc++6               6.3.0-6

Versions of packages clang-4.0 recommends:
ii  llvm-4.0-dev  1:4.0~+rc2-1
ii  python        2.7.13-2

Versions of packages clang-4.0 suggests:
pn  clang-4.0-doc  <none>
pn  gnustep        <none>
pn  gnustep-devel  <none>

-- no debconf information



More information about the Pkg-llvm-team mailing list