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

[Bjoern Kahl]

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.



>> 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 :-)) |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 356 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140206/2df2807e/attachment.sig>