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