[lldb-dev] Building lldb on OS X

[Todd Fiala]

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