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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 < >>> [email protected]> 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 >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>> >>> >>> >>> >>> -- >>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>> >> >> > > > -- > Todd Fiala | Software Engineer | [email protected] | 650-943-3180 > -- Todd Fiala | Software Engineer | [email protected] | 650-943-3180
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
