On Thu, Aug 7, 2008 at 5:46 PM, David Shipman <dshipman at gmail.com> wrote:> I've just tried building r54494 on 64bit linux and had the same (no > include path) > error. Any idea what's happening here? >No. :-( Could you try Mike's suggestion? (Replicated here) Try adding: #define _GCC_LIMITS_H_ to limitx.h like so: #ifdef _GCC_NEXT_LIMITS_H +#define _GCC_LIMITS_H_ #include_next <limits.h> #undef _GCC_NEXT_LIMITS_H and then testing. A good test would do a -dM -E and seeing if everything is still defined and checking the testcase mentioned in the original email thread.
Mike's suggestion seems to fix the problem - happy to use it, although my impression is that it shouldn't be necessary? -David Shipman On Fri, Aug 8, 2008 at 12:59 PM, Bill Wendling <isanbard at gmail.com> wrote:> On Thu, Aug 7, 2008 at 5:46 PM, David Shipman <dshipman at gmail.com> wrote: >> I've just tried building r54494 on 64bit linux and had the same (no >> include path) >> error. Any idea what's happening here? >> > No. :-( Could you try Mike's suggestion? (Replicated here) > > Try adding: > > #define _GCC_LIMITS_H_ > > to limitx.h like so: > > #ifdef _GCC_NEXT_LIMITS_H > +#define _GCC_LIMITS_H_ > #include_next <limits.h> > #undef _GCC_NEXT_LIMITS_H > > and then testing. A good test would do a -dM -E and seeing if > everything is still defined and checking the testcase mentioned in the > original email thread. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Header files are tricky beasts. :-) I'll go ahead and apply that to the tree. Thanks for testing it out. -bw On Aug 7, 2008, at 6:32 PM, "David Shipman" <dshipman at gmail.com> wrote:> Mike's suggestion seems to fix the problem - happy to use it, > although my impression is that it shouldn't be necessary? > > -David Shipman > > On Fri, Aug 8, 2008 at 12:59 PM, Bill Wendling <isanbard at gmail.com> > wrote: >> On Thu, Aug 7, 2008 at 5:46 PM, David Shipman <dshipman at gmail.com> >> wrote: >>> I've just tried building r54494 on 64bit linux and had the same (no >>> include path) >>> error. Any idea what's happening here? >>> >> No. :-( Could you try Mike's suggestion? (Replicated here) >> >> Try adding: >> >> #define _GCC_LIMITS_H_ >> >> to limitx.h like so: >> >> #ifdef _GCC_NEXT_LIMITS_H >> +#define _GCC_LIMITS_H_ >> #include_next <limits.h> >> #undef _GCC_NEXT_LIMITS_H >> >> and then testing. A good test would do a -dM -E and seeing if >> everything is still defined and checking the testcase mentioned in >> the >> original email thread. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> to limitx.h like so: > > #ifdef _GCC_NEXT_LIMITS_H > +#define _GCC_LIMITS_H_ > #include_next <limits.h> > #undef _GCC_NEXT_LIMITS_HThis fixes this problem for me on Ubuntu Hardy on x86-64. John
Okay. I've applied this patch. I hope it helps out. :-) -bw On Aug 7, 2008, at 8:07 PM, John Regehr wrote:>> to limitx.h like so: >> >> #ifdef _GCC_NEXT_LIMITS_H >> +#define _GCC_LIMITS_H_ >> #include_next <limits.h> >> #undef _GCC_NEXT_LIMITS_H > > This fixes this problem for me on Ubuntu Hardy on x86-64. > > John > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Aug 7, 2008, at 6:32 PM, David Shipman wrote:> Mike's suggestion seems to fix the problem - happy to use it, > although my impression is that it shouldn't be necessary?That's right, in a clean world there would be no coupling on the compiler from /usr/include. You can go flame glibc. But, it really isn't quite their fault either, there are insane requirements pushed onto the `vendor' of the headers, and it was engineered to loose. The gcc patch `hacks' around this coupling by preserving the magic (interal implementation detail) `interface' to the header file.