[llvm-bugs] [Bug 28993] New: Unexpected #include_next behavior on clang 3.8

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Aug 15 18:19:38 PDT 2016


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: unassignedclangbugs at nondot.org
          Reporter: pumpkin at me.com
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160816/0b243165/attachment.html>


More information about the llvm-bugs mailing list