[lldb-dev] Building lldb on OS X

Todd Fiala tfiala at google.com
Wed Jul 23 10:58:21 PDT 2014 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140723/41c21d28/attachment.html>

More information about the lldb-dev mailing list