https://llvm.org/bugs/show_bug.cgi?id=28993
Bug ID: 28993
Summary: Unexpected #include_next behavior on clang 3.8
Product: clang
Version: 3.8
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: pump...@me.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16964
--> https://llvm.org/bugs/attachment.cgi?id=16964&action=edit
Small reproduction
As of 3.8, libc++ now bundles a small stdlib.h that does #include_next to get
the real stdlib.h. My issues arise in the following scenario:
- I'm building libc++abi 3.8.0
- I'm building it on a host with llvm/clang/libc++/libc++abi all at 3.8.0
- To build, I need to provide libc++abi's build process with the libc++ source
code
- My libc++abi build fails complaining about a bunch of missing stdlib.h
identifiers
- Upon deeper investigation, it turns out that the proper glibc stdlib.h never
gets #included into the compilation
>From what I can gather from -v, my search path looks something like:
1. Headers from libc++ source tree I pass to libc++abi build
2. System libc++ headers
3. A couple more unrelated things
4. glibc headers (which I've checked indeed do contain a valid stdlib.h)
Judging by -E and -H, clang++ seems to decide that it's included enough after
step #2 above, and never makes its way down to #4 to get my system stdlib.h.
I'm attaching a reduced test case that demonstrates my confusion. The tarball
contains test.sh and test2.sh that demonstrate the problem with both -I and
-isystem on a brand new vanilla Ubuntu 14.04 instance that I just installed
clang 3.8 onto as well as standard development tools to get system headers.
Not sure if I'm doing something wrong, but this behavior doesn't fit what I'd
expect of #include_next.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
