[lldb-dev] Building lldb on OS X

Todd Fiala tfiala at google.com
Wed Jul 23 11:01:31 PDT 2014 

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 <tfiala at google.com> 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 <
> kfischer at college.harvard.edu> 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 <tfiala at google.com> 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 <tfiala at google.com> 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 <
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> 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/d280dcb3/attachment.html>

More information about the lldb-dev mailing list