[lldb-dev] LLDB @ Mac OSX: build on Snow Leopard (still) supported? [patch]

[Jean-Daniel Dupas]

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
>> #endif
>> #endif
>> 
>> 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>".
> 
> 
> Björn
> 
> -- 
> |     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
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

-- Jean-Daniel