our unwind.h is fairly complete these days. Do you know what is missing from it so that it can be used without the include_next check?
why is a fresh build of clang using searching /usr/include/clang/3.4/include? That looks like a bug. These headers are compiler specific. On 12 November 2013 09:14, Sylvestre Ledru <[email protected]> wrote: > Without this patch, the first local include of unwind.h might, with the > __has_include_next, try to include the one from the system. > It might be /usr/include/clang/3.4/include/unwind.h > Because of the #ifndef __CLANG_UNWIND_H, it might never include any > declaration from the system. > > This patch is applied in http://llvm.org/apt/ It enables the build of clang > with the Debian packages installed on the system. > > > http://llvm-reviews.chandlerc.com/D2150 > > Files: > lib/Headers/unwind.h > > Index: lib/Headers/unwind.h > =================================================================== > --- lib/Headers/unwind.h > +++ lib/Headers/unwind.h > @@ -23,9 +23,6 @@ > > /* See "Data Definitions for libgcc_s" in the Linux Standard Base.*/ > > -#ifndef __CLANG_UNWIND_H > -#define __CLANG_UNWIND_H > - > #if __has_include_next(<unwind.h>) > /* Darwin (from 11.x on) and libunwind provide an unwind.h. If that's > available, > * use it. libunwind wraps some of its definitions in #ifdef _GNU_SOURCE, > @@ -53,6 +50,9 @@ > # endif > #else > > +#ifndef __CLANG_UNWIND_H > +#define __CLANG_UNWIND_H > + > #include <stdint.h> > > #ifdef __cplusplus > @@ -275,6 +275,7 @@ > } > #endif > > +#endif /* __CLANG_UNWIND_H */ > + > #endif > > -#endif /* __CLANG_UNWIND_H */ > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
