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