Might be relevant: that /usr/include path is resolved within the Xcode SDK that is being built against, which is buried within the Xcode distribution.
On my setup, it really comes from here: Xcode6-Beta4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk. (usr/include is under that). -Todd On Wed, Jul 23, 2014 at 10:58 AM, Todd Fiala <[email protected]> wrote: > I could see that being the case. This is coming from Xcode 6 Beta. If > you were on that, it would be broken. > > It might be best to have the Apple guys weigh in on their suggestion here > since we're getting way out of my area of focus. > > Greg/Jim? > > > On Wed, Jul 23, 2014 at 10:51 AM, Keno Fischer < > [email protected]> wrote: > >> On 10.9.4, my /usr/include/mach/machine.h does not include that >> constant. >> >> >> On Wed, Jul 23, 2014 at 10:48 AM, Todd Fiala <[email protected]> wrote: >> >>> Okay - so this patch won’t work on MacOSX Xcode builds - it starts >>> picking up the wrong definition of that symbol (from machine.h): >>> >>> Index: source/Host/common/Host.cpp >>> =================================================================== >>> --- source/Host/common/Host.cpp (revision 213770) >>> +++ source/Host/common/Host.cpp (working copy) >>> @@ -32,6 +32,8 @@ >>> #include <sys/sysctl.h> >>> #endif >>> >>> +#include "lldb/Utility/SafeMachO.h" >>> + >>> #if defined (__APPLE__) >>> #include <mach/mach_port.h> >>> #include <mach/mach_init.h> >>> @@ -368,7 +370,7 @@ >>> // Now we need modify the cpusubtype for the 32 bit slices. >>> uint32_t cpusubtype32 = cpusubtype; >>> #if defined (__i386__) || defined (__x86_64__) >>> - if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype == >>> CPU_SUBTYPE_X86_64_H) >>> + if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype == >>> llvm::MachO::CPU_SUBTYPE_X86_64_H) >>> cpusubtype32 = CPU_SUBTYPE_I386_ALL; >>> #elif defined (__arm__) || defined (__arm64__) || defined (__aarch64__) >>> if (cputype == CPU_TYPE_ARM || cputype == CPU_TYPE_ARM64) >>> >>> It is picking up this definition: >>> >>> #define CPU_SUBTYPE_X86_64_H ((cpu_subtype_t)8) /* Haswell >>> feature subset */ >>> >>> from /usr/include/mach/machine.h. >>> >>> I think the path we’ll want to figure out is how to adjust the makefile >>> include paths to better match the Xcode build. >>> >>> I can probably dump out a compile execution of that file in Xcode the >>> figure out what specifically it is using, in which case you can see how the >>> Makefile is building the include path and perhaps adjust that properly for >>> MacOSX? >>> >>> -Todd >>> >>> >>> >>> On Wed, Jul 23, 2014 at 10:37 AM, Todd Fiala <[email protected]> wrote: >>> >>>> No problem, just wanted to make sure I'm using the code you intended >>>> :-) Thanks! >>>> >>>> >>>> On Wed, Jul 23, 2014 at 10:34 AM, Keno Fischer < >>>> [email protected]> wrote: >>>> >>>>> Sorry, yeah it got truncated, basically just prepend llvm::MachO:: to >>>>> CPU_SUBTYPE_X86_64_H. >>>>> Sorry about that. >>>>> >>>>> >>>>> On Wed, Jul 23, 2014 at 10:32 AM, Todd Fiala <[email protected]> >>>>> wrote: >>>>> >>>>>> Hm is the patch here what you really wanted? It might be getting >>>>>> truncated? >>>>>> >>>>>> - if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype == >>>>>> CPU_SUBTYPE_ >>>>>> + if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype == >>>>>> llvm::MachO: >>>>>> >>>>>> Seems incomplete. >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 10:24 AM, Todd Fiala <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I'll go ahead and give it a run on Xcode. If it doesn't break >>>>>>> anything there, sure I'll go ahead and commit it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 23, 2014 at 10:22 AM, Keno Fischer < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Does the Xcode build automatically include SafeMachO.h? Also, any >>>>>>>> harm in just committing that patch, if not would you mind doing that (I >>>>>>>> don't have commit access)? >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 23, 2014 at 10:17 AM, Todd Fiala <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ok. Sounds like there are header ordering differences between >>>>>>>>> configure/make and the Xcode build. That might be causing issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jul 23, 2014 at 10:14 AM, Keno Fischer < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Ok, figured it out. The position of the SafeMachO.h header >>>>>>>>>> matters. This works: >>>>>>>>>> >>>>>>>>>> ``` >>>>>>>>>> diff --git a/source/Host/common/Host.cpp >>>>>>>>>> b/source/Host/common/Host.cpp >>>>>>>>>> index 275b446..3802224 100644 >>>>>>>>>> --- a/source/Host/common/Host.cpp >>>>>>>>>> +++ b/source/Host/common/Host.cpp >>>>>>>>>> @@ -32,6 +32,8 @@ >>>>>>>>>> #include <sys/sysctl.h> >>>>>>>>>> #endif >>>>>>>>>> >>>>>>>>>> +#include "lldb/Utility/SafeMachO.h" >>>>>>>>>> + >>>>>>>>>> #if defined (__APPLE__) >>>>>>>>>> #include <mach/mach_port.h> >>>>>>>>>> #include <mach/mach_init.h> >>>>>>>>>> @@ -368,7 +370,7 @@ Host::GetArchitecture >>>>>>>>>> (SystemDefaultArchitecture arch_kind) >>>>>>>>>> // Now we need modify the cpusubtype for the 32 >>>>>>>>>> bit slices. >>>>>>>>>> uint32_t cpusubtype32 = cpusubtype; >>>>>>>>>> #if defined (__i386__) || defined (__x86_64__) >>>>>>>>>> - if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype >>>>>>>>>> == CPU_SUBTYPE_ >>>>>>>>>> + if (cpusubtype == CPU_SUBTYPE_486 || cpusubtype >>>>>>>>>> == llvm::MachO: >>>>>>>>>> cpusubtype32 = CPU_SUBTYPE_I386_ALL; >>>>>>>>>> #elif defined (__arm__) || defined (__arm64__) || defined >>>>>>>>>> (__aarch64__) >>>>>>>>>> if (cputype == CPU_TYPE_ARM || cputype == >>>>>>>>>> CPU_TYPE_ARM64) >>>>>>>>>> ``` >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jul 23, 2014 at 10:04 AM, Keno Fischer < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> I don't think that file is included from Host.cpp or am I >>>>>>>>>>> missing something? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Jul 23, 2014 at 9:59 AM, Todd Fiala <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> It comes from llvm/include/llvm/Support/MachO.h, line 1261. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:57 AM, Keno Fischer < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Through which path is that constant supposed to be defined? I >>>>>>>>>>>>> can check that all those are picked up correctly. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:55 AM, Todd Fiala <[email protected] >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Ok. Definitely sounds worth of opening up a llvm.org/bugs >>>>>>>>>>>>>> ticket on. That way you can attach your make logs and whatnot. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Based on what you reported so far, it sounds like perhaps the >>>>>>>>>>>>>> build is picking up headers from the wrong place (i.e. maybe >>>>>>>>>>>>>> configure is >>>>>>>>>>>>>> finding the wrong llvm code, or something that is causing >>>>>>>>>>>>>> headers from one >>>>>>>>>>>>>> place to get used with code from another, perhaps between the >>>>>>>>>>>>>> local lldb >>>>>>>>>>>>>> and llvm/clang code). >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Todd >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:51 AM, Keno Fischer < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> That's not really a great option, because it means I have to >>>>>>>>>>>>>>> maintain three build systems on my side with three different >>>>>>>>>>>>>>> configurations, especially because the rest of llvm/clang >>>>>>>>>>>>>>> builds just fine >>>>>>>>>>>>>>> with Makefiles. I will track down why this fails and submit a >>>>>>>>>>>>>>> patch. Since >>>>>>>>>>>>>>> this is the only issue preventing a clean build of lldb with >>>>>>>>>>>>>>> Makefiles, I >>>>>>>>>>>>>>> think that will be significantly less work than adjusting the >>>>>>>>>>>>>>> rest of the >>>>>>>>>>>>>>> pipeline to work with three build systems. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:26 AM, Todd Fiala < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ok I did an Xcode and Ubuntu 14.04 build at llvm, clang and >>>>>>>>>>>>>>>> lldb r213767 (just a few minutes ago), and those all worked. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Are you in a position where you can use the Xcode build on >>>>>>>>>>>>>>>> MacOSX? If so, that's definitely the way to go. cmake gets >>>>>>>>>>>>>>>> little >>>>>>>>>>>>>>>> attention there, and frankly I didn't even know the >>>>>>>>>>>>>>>> configure/make build on >>>>>>>>>>>>>>>> MacOSX even worked. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At the moment we're struggling with having 3 build systems. >>>>>>>>>>>>>>>> At best we're maintaining the canonical build system for a >>>>>>>>>>>>>>>> given platform. >>>>>>>>>>>>>>>> Right now that seems to be Xcode for MacOSX, cmake for Ubuntu >>>>>>>>>>>>>>>> and FreeBSD. >>>>>>>>>>>>>>>> make/configure seems to be used by Debian's 'build (maybe FC >>>>>>>>>>>>>>>> too?). I >>>>>>>>>>>>>>>> would recommend attempting to use the canonical build system >>>>>>>>>>>>>>>> for lldb on a >>>>>>>>>>>>>>>> given platform to minimize difficulties since those will tend >>>>>>>>>>>>>>>> to get fixed >>>>>>>>>>>>>>>> quickly when they do break on the given platform. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:13 AM, Todd Fiala < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ah shucks, ok. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I did fix a build issue that occurred this morning due to >>>>>>>>>>>>>>>>> some changes in llvm, but I don't think I hit that one. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'll do a quick sync now just to see if maybe that crept >>>>>>>>>>>>>>>>> in over the last hour or two since I came in. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Todd >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:11 AM, Keno Fischer < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> No, I'm doing a Makefile build. LLVM/Clang/LLDB are all >>>>>>>>>>>>>>>>>> at latest trunk. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 9:06 AM, Todd Fiala < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hey Keno! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Are you doing an Xcode build? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If so, you may be suffering from what I did when I first >>>>>>>>>>>>>>>>>>> started using Xcode builds. Xcode puts the llvm and >>>>>>>>>>>>>>>>>>> llvm/tools/clang >>>>>>>>>>>>>>>>>>> directory underneath the lldb directory. It does a sync >>>>>>>>>>>>>>>>>>> the first time for >>>>>>>>>>>>>>>>>>> you, but not after that. So, you may be dealing with an >>>>>>>>>>>>>>>>>>> llvm and clang >>>>>>>>>>>>>>>>>>> tree that are out of date with respect to your version of >>>>>>>>>>>>>>>>>>> llvm. If that's >>>>>>>>>>>>>>>>>>> the case, just do this: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> cd /your/lldb/path >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> cd llvm >>>>>>>>>>>>>>>>>>> svn update >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> cd tools/clang >>>>>>>>>>>>>>>>>>> svn update >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> # Put you back in the lldb dir >>>>>>>>>>>>>>>>>>> cd ../../.. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Then redo your build of lldb. It will run the auto >>>>>>>>>>>>>>>>>>> llvm/clang build step (somewhat long), then get back to >>>>>>>>>>>>>>>>>>> building lldb. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Let me know if that solves your issue! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -Todd >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Jul 23, 2014 at 8:43 AM, Keno Fischer < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> While building on OS X I have been sent reports of the >>>>>>>>>>>>>>>>>>>> following (I >>>>>>>>>>>>>>>>>>>> did see it myself at one point as well, but worked >>>>>>>>>>>>>>>>>>>> around it). I tried >>>>>>>>>>>>>>>>>>>> including SafeMachO.h but that caused other problems in >>>>>>>>>>>>>>>>>>>> the llvm >>>>>>>>>>>>>>>>>>>> headers. What's the proper way to get around this other >>>>>>>>>>>>>>>>>>>> than `#define >>>>>>>>>>>>>>>>>>>> CPU_SUBTYPE_X86_64_H 8`? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> lldb/source/Host/common/Host.cpp:371:68: error: use of >>>>>>>>>>>>>>>>>>>> undeclared >>>>>>>>>>>>>>>>>>>> identifier 'CPU_SUBTYPE_X86_64_H' >>>>>>>>>>>>>>>>>>>> if (cpusubtype == CPU_SUBTYPE_486 || >>>>>>>>>>>>>>>>>>>> cpusubtype == >>>>>>>>>>>>>>>>>>>> CPU_SUBTYPE_X86_64_H) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Keno >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> lldb-dev mailing list >>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>>>>> 650-943-3180 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>>>> 650-943-3180 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>> >>> >>> >>> >>> -- >>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>> >> >> > > > -- > Todd Fiala | Software Engineer | [email protected] | 650-943-3180 > -- Todd Fiala | Software Engineer | [email protected] | 650-943-3180
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
