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
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
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
No, I’m doing a Makefile build. LLVM/Clang/LLDB are all at latest trunk.
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
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.
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.
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
Through which path is that constant supposed to be defined? I can check that all those are picked up correctly.
It comes from llvm/include/llvm/Support/MachO.h, line 1261.
I suppose I left out a big one here, for completeness:
We’re doing a lot of work on getting Windows up and running, and configure/make is definitely out there. Cmake is the canonical build generator (configurator) for Windows. Generating Ninja for building and VS for code editing is the way that platform works.
If I had to guess, I would expect configure/make build support in lldb is going to get less and less attention unless somebody steps in to actively maintain it in a testable way.
I don’t think that file is included from Host.cpp or am I missing something?
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"Ok. Sounds like there are header ordering differences between configure/make and the Xcode build. That might be causing issues.
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)?
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.
Hm is the patch here what you really wanted? It might be getting truncated?
Seems incomplete.
Sorry, yeah it got truncated, basically just prepend llvm::MachO:: to CPU_SUBTYPE_X86_64_H. Sorry about that.
No problem, just wanted to make sure I’m using the code you intended 
Thanks!
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.cppOn 10.9.4, my /usr/include/mach/machine.h does not include that constant.