[lldb-dev] Building lldb on OS X

Todd Fiala tfiala at google.com
Wed Jul 23 10:37:03 PDT 2014 

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 <kfischer at college.harvard.edu
> 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 <tfiala at google.com> 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 <tfiala at google.com> 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 <
>>> kfischer at college.harvard.edu> 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 <tfiala at google.com> 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 <
>>>>> kfischer at college.harvard.edu> 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 <
>>>>>> kfischer at college.harvard.edu> 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 <tfiala at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> It comes from llvm/include/llvm/Support/MachO.h, line 1261.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jul 23, 2014 at 9:57 AM, Keno Fischer <
>>>>>>>> kfischer at college.harvard.edu> 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 <tfiala at google.com>
>>>>>>>>> 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 <
>>>>>>>>>> kfischer at college.harvard.edu> 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 <tfiala at google.com>
>>>>>>>>>>> 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 <tfiala at google.com>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> kfischer at college.harvard.edu> 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 <
>>>>>>>>>>>>>> tfiala at google.com> 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 <
>>>>>>>>>>>>>>> kfischer at college.harvard.edu> 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
>>>>>>>>>>>>>>>> lldb-dev at cs.uiuc.edu
>>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>>>>>>> 650-943-3180
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>>>>> 650-943-3180
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>>>> 650-943-3180
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |
>>>>>>>>>> 650-943-3180
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>>
>>
>>
>>
>> --
>> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140723/feac7b31/attachment.html>

More information about the lldb-dev mailing list