[lldb-dev] Building lldb on OS X
Todd Fiala
tfiala at google.com
Wed Jul 23 10:17:14 PDT 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140723/1f5c0058/attachment.html>
More information about the lldb-dev
mailing list