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