[lldb-dev] LLDB @ Mac OSX: build on Snow Leopard (still) supported? [patch]
devlists at shadowlab.org
Wed Feb 5 16:42:20 PST 2014
Le 6 févr. 2014 à 00:42, Bjoern Kahl <mls at bjoern-kahl.de> a écrit :
> Am 05.02.14 23:22, schrieb Jason Molenda:
>> On Feb 5, 2014, at 1:35 PM, Bjoern Kahl <mls at bjoern-kahl.de> wrote:
>>> 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.
> 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
> :-) 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
>> to 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>".
> | Bjoern Kahl +++ Siegburg +++ Germany |
> | "googlelogin at -my-domain-" +++ www.bjoern-kahl.de |
> | Languages: German, English, Ancient Latin (a bit :-)) |
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
More information about the lldb-dev