Dear All,
according to the web page, building with XCode 3.x is supported, but
trying so result in build failures, both when using xcodebuild as well
as when following the (FreeBSD) "make" instructions.
So my question is:
Is building LLDB on Mac OSX Snow Leopard (still) supported?
If yes, how can I fix the build failures, preferably the make based
ones in the second part of this mail?
First, trying XCode as suggested on http://lldb.llvm.org/build.html,
failed as follows:
Try:
svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb
cd lldb
xcodebuild -configuration Debug
The current LLDB and clang sources require C++11, and I am not sure how good the C++11 compiler was on SnowLeopard.
Greg
Dear All,
according to the web page, building with XCode 3.x is supported, but
trying so result in build failures, both when using xcodebuild as well
as when following the (FreeBSD) "make" instructions.So my question is:
Is building LLDB on Mac OSX Snow Leopard (still) supported?
If yes, how can I fix the build failures, preferably the make based
ones in the second part of this mail?
I think we need to update http://lldb.llvm.org/build.html and remove mentions of Xcode 3 -- and I don't think anyone has tried building current-lldb on Snow Leopard (Mac OS X 10.6) in a very long time and it is (clearly) not working. We've tried to keep it building for Mac OS X 10.7 ("Lion") because there are a few people still running Lion but I don't think we've heard from people using Snow Leopard.
Most of the active lldb developers are running the current Mac OS X 10.9 release ("Mavericks") - I don't think anyone has a system still running Snow Leopard. Greg would be better able to answer how receptive he would be to accepting patches to make it build on 10.6 again - but given that you have to use a non-Apple gcc release (so e.g. no Objective-C++ support) it may be a bit of work.
Why do I need to checkout *and* *compile* a separate llvm and clang
tree to build LLDB, even when the system has an installed llvm and
clang?
llvm/clang are a compiler library that lldb uses to evaluate expressions from the user ("p 5 + (int)getpid()"). The API of this library is not intended to be stable. Top of tree svn lldb builds against the TOT svn llvm/clang, and when API are changed in TOT llvm/clang, lldb changes to keep building against them.
J
Hi Jason,
hi All,
according to the web page, building with XCode 3.x is supported, but
trying so result in build failures, both when using xcodebuild as well
as when following the (FreeBSD) "make" instructions.So my question is:
Is building LLDB on Mac OSX Snow Leopard (still) supported?
If yes, how can I fix the build failures, preferably the make based
ones in the second part of this mail?I think we need to update http://lldb.llvm.org/build.html and remove mentions of Xcode 3 -- and I don't think anyone has tried building current-lldb on Snow Leopard (Mac OS X 10.6) in a very long time and it is (clearly) not working. We've tried to keep it building for Mac OS X 10.7 ("Lion") because there are a few people still running Lion but I don't think we've heard from people using Snow Leopard.
Well, I am still on Snow Leopard, and I intent to stay there for the
foreseeable future. 
Most of the active lldb developers are running the current Mac OS X 10.9 release ("Mavericks") - I don't think anyone has a system still running Snow Leopard. Greg would be better able to answer how receptive he would be to accepting patches to make it build on 10.6 again - but given that you have to use a non-Apple gcc release (so e.g. no Objective-C++ support) it may be a bit of work.
Actually, after a lot of tries, I succeeded to build current-lldb with
only minimal changes to its source. I had to touch only four files
(patch attached, but needs additional configure test):
lib/Makefile : added -lpanel
source/Host/common/FileSpec.cpp : added missing #include <limits.h>
source/Host/common/Host.cpp : worked around pthread_fchdir()
source/Host/macosx/Host.mm : worked around pthread_fchdir()
That's all for LLDB.
Attached patch contains these changes, but misses an appropriate
configure test. Unfortunately, I have no idea how configure scripts
are made or work, so can't help with the test.
Fixing toolchain:
The major work was, to get a working clang-3.5. Although provided
by MacPorts, a simple "port install clang-3.5" results in a toolchain
with partially broken libc++ so that, among other things, clang++
can't parse its own cmath header. But that is something I should
probably discuss with the clang / libcxx developers.
Here are all steps I needed to do:
- port install gcc-48
- svn checkout of llvm, clang, libcxx, libcxxabi into the prescribed tree:
llvm -+- projects -+- libcxx
> +- libcxxabi
+- tools --- clang
- cd llvm/projects
- patch libcxx and libcxxabi to install into /usr/local instead of /usr
(they don't honor the "--prefix" from configure)
- mkdir mybuild && cd mybuild
- ../llvm/configure --prefix=/usr/local --enable-cxx11
--enable-optimized CC=/opt/local/bin/gcc CXX=/opt/local/bin/g++
- make && sudo make install
- fix /usr/local/include/c++/v1/cmath
to "extern C" llrint and llround
- svn checkout lldb into llvm/tools/lldb
- ../llvm/configure --prefix=/usr/local --enable-cxx11 --enable-libcpp
--enable-optimized CC=/usr/local/bin/clang CXX=/usr/local/bin/clang++
- make && sudo make install
If someone wants it, I can put together a script that automates the
whole process including all patches / fixups.
Björn
lldb-patch-snowleopard.txt (2.82 KB)
Well, I am still on Snow Leopard, and I intent to stay there for the
foreseeable future.
I think it's worth distinguishing between Snow Leopard build issues (e.g. the patch you attached) and issues of building a Mac OS X native lldb with a non-clang compiler like gcc 4.8 & the GNU libstdc++. The last gcc release that Apple had (with Objective-C++ support) was 4.2.1 or so - which obviously won't work for lldb because of the C++11 use in the codebase.
Actually, after a lot of tries, I succeeded to build current-lldb with
only minimal changes to its source. I had to touch only four files
(patch attached, but needs additional configure test):lib/Makefile : added -lpanel
source/Host/common/FileSpec.cpp : added missing #include <limits.h>
source/Host/common/Host.cpp : worked around pthread_fchdir()
source/Host/macosx/Host.mm : worked around pthread_fchdir()That's all for LLDB.
Where did you define CONFIG_HAS_PTHREAD_CHDIR for your build? It might be easier to add something like
#if defined(__APPLE)
#include <AvailabilityMacros.h>
#if MAC_OS_X_VERSION_MIN_REQUIRED > MAC_OS_X_VERSION_10_6
// __pthread_chdir and __pthread_fchdir are only available on Mac OS X 10.7 and later
#define CONFIG_HAS_PTHREAD_CHDIR
#endif
#endif
to common/Host.cpp.
Well, I am still on Snow Leopard, and I intent to stay there for the
foreseeable future.
I am not sure I understand you correctly.
Do you mean by "Mac OS X native lldb" to build with just the plain
Mac OS X + Xcode installed?
I agree, that would probably be close to impossible.
Building with Mac OS X + some decent OSS environment (MacPorts,
Homebrew, Fink, ...) shouldn't be to hard. I don't think the problems
I had should exists.
In fact, I almost succeeded with the gcc-48, which has Objective-C
support, but apparently not the latest, i.e. no "blocks" support, at
least I found no option that enables this.
Trying clang was a major disappointment, because without "--enable-libcpp"
configure just complained about a to old libc++ (it couldn't find
"atomic" header), and with "--enable-libcpp" configure completed but
the build failed in the first file including cmath due to missing
declarations of llrint() and llround(). I guess I could have just
hacked the systems cmath instead of installing a separate toolchain
and libc++ in /usr/local, but I didn't want to touch system files.
Actually, after a lot of tries, I succeeded to build current-lldb with
only minimal changes to its source. I had to touch only four files
(patch attached, but needs additional configure test):lib/Makefile : added -lpanel
source/Host/common/FileSpec.cpp : added missing #include <limits.h>
source/Host/common/Host.cpp : worked around pthread_fchdir()
source/Host/macosx/Host.mm : worked around pthread_fchdir()That's all for LLDB.
Where did you define CONFIG_HAS_PTHREAD_CHDIR for your build? It might be easier to add something like
Nowhere. The point was to have the pthread_chdir() code "ifdef'ed out"
and use the variant for platforms that don't have these calls.
My intention was to have a configure test, if the platform supports it
and then have or have not a "#define" in config.h. Conditioning on a
vendor isn't optimal, because other platforms may at some point also
develop that pthread feature.
#if defined(__APPLE)
#include <AvailabilityMacros.h>
#if MAC_OS_X_VERSION_MIN_REQUIRED > MAC_OS_X_VERSION_10_6
// __pthread_chdir and __pthread_fchdir are only available on Mac OS X 10.7 and later
#define CONFIG_HAS_PTHREAD_CHDIR
#endif
#endifto common/Host.cpp.
Looks good to me, and much simpler then a vendor neutral test in
configure. I've added it to my tree, using "<Availability.h>".
Björn
Well, I am still on Snow Leopard, and I intent to stay there for the
foreseeable future.
I am not sure I understand you correctly.
Do you mean by "Mac OS X native lldb" to build with just the plain
Mac OS X + Xcode installed?I agree, that would probably be close to impossible.
Building with Mac OS X + some decent OSS environment (MacPorts,
Homebrew, Fink, ...) shouldn't be to hard. I don't think the problems
I had should exists.In fact, I almost succeeded with the gcc-48, which has Objective-C
support, but apparently not the latest, i.e. no "blocks" support, at
least I found no option that enables this.Trying clang was a major disappointment, because without "--enable-libcpp"
configure just complained about a to old libc++ (it couldn't find
"atomic" header), and with "--enable-libcpp" configure completed but
the build failed in the first file including cmath due to missing
declarations of llrint() and llround(). I guess I could have just
hacked the systems cmath instead of installing a separate toolchain
and libc++ in /usr/local, but I didn't want to touch system files.
The llrint/llround issue is well known when using clang on 10.6.
If you are compiling in a standard mode (aka -std=c++11), the system header will incorrectly exclude some maths functions.
This is not a compiler bug but a OS X SDK bug.
You can either try to use a gnu mode instead -std=gnu++11 or undefined the __STRICT_ANSI__ macro via some compiler flags:
clang -std=c++11 -U__STRICT_ANSI__
Actually, after a lot of tries, I succeeded to build current-lldb with
only minimal changes to its source. I had to touch only four files
(patch attached, but needs additional configure test):lib/Makefile : added -lpanel
source/Host/common/FileSpec.cpp : added missing #include <limits.h>
source/Host/common/Host.cpp : worked around pthread_fchdir()
source/Host/macosx/Host.mm : worked around pthread_fchdir()That's all for LLDB.
Where did you define CONFIG_HAS_PTHREAD_CHDIR for your build? It might be easier to add something like
and use the variant for platforms that don't have these calls.My intention was to have a configure test, if the platform supports it
and then have or have not a "#define" in config.h. Conditioning on a
vendor isn't optimal, because other platforms may at some point also
develop that pthread feature.#if defined(__APPLE)
#include <AvailabilityMacros.h>
#if MAC_OS_X_VERSION_MIN_REQUIRED > MAC_OS_X_VERSION_10_6
// __pthread_chdir and __pthread_fchdir are only available on Mac OS X 10.7 and later
#define CONFIG_HAS_PTHREAD_CHDIR
#endif
#endifto common/Host.cpp.
Looks good to me, and much simpler then a vendor neutral test in
configure. I've added it to my tree, using "<Availability.h>".Björn
--
> Bjoern Kahl +++ Siegburg +++ Germany |
> "googlelogin@-my-domain-" +++ www.bjoern-kahl.de |
> Languages: German, English, Ancient Latin (a bit :-)) |_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
-- Jean-Daniel