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
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
