Le 6 févr. 2014 à 00:42, Bjoern Kahl <[email protected]> a écrit :
> Am 05.02.14 23:22, schrieb Jason Molenda: >> >> On Feb 5, 2014, at 1:35 PM, Bjoern Kahl <[email protected]> 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@-my-domain-" +++ www.bjoern-kahl.de | > | Languages: German, English, Ancient Latin (a bit :-)) | > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev -- Jean-Daniel _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
