Yes, isn't that amazing?! Benjamin Hindman did an awesome job. All tests passed here as well.
On 04 Jan 2014, at 22:39, Yan Xu <[email protected]> wrote: > Excellent! I ran it on Mavericks and all tests passed! > > -- > Jiang Yan Xu <[email protected]> @xujyan <http://twitter.com/xujyan> > > > On Fri, Jan 3, 2014 at 10:46 AM, Jie Yu <[email protected]> wrote: > >> It compiled with gcc-4.8 (installed via brew) on my Mac OS X 10.8.5 >> >> I guess the reason why clang on my mac does not work is because the libc++ >> headers (/usr/include/c++/v1) are not compatible with the clang I have >> installed. >> >> - Jie >> >> >> On Thu, Jan 2, 2014 at 1:54 PM, Jie Yu <[email protected]> wrote: >> >>> I cannot compile it on my mac. >>> >>> Mac OS X Version 10.8.5 >>> clang 3.3 >>> >>> [tw-mbp-jyu bin]$ /Users/jyu/tool/llvm/3.3/bin/clang++ -v >>> clang version 3.3 (tags/RELEASE_33/final) >>> Target: x86_64-apple-darwin12.5.0 >>> Thread model: posix >>> >>> CC=/Users/jyu/tool/llvm/3.3/bin/clang >>> CXX=/Users/jyu/tool/llvm/3.3/bin/clang++ ../configure >>> --prefix=/Users/jyu/workspace/mesos-benh/dist >>> >>> --------------------------------- >>> >>> /bin/sh ./libtool --tag=CXX --mode=compile >>> /Users/jyu/tool/llvm/3.3/bin/clang++ -DHAVE_CONFIG_H -I. -I./src -I./src >>> -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare >>> -DNO_FRAME_POINTER -DNDEBUG -DGTEST_USE_OWN_TR1_TUPLE=1 -g -g2 -O2 >>> -std=c++11 -stdlib=libc++ -MT libglog_la-logging.lo -MD -MP -MF >>> .deps/libglog_la-logging.Tpo -c -o libglog_la-logging.lo `test -f >>> 'src/logging.cc' || echo './'`src/logging.cc >>> libtool: compile: /Users/jyu/tool/llvm/3.3/bin/clang++ -DHAVE_CONFIG_H >>> -I. -I./src -I./src -Wall -Wwrite-strings -Woverloaded-virtual >>> -Wno-sign-compare -DNO_FRAME_POINTER -DNDEBUG -DGTEST_USE_OWN_TR1_TUPLE=1 >>> -g -g2 -O2 -std=c++11 -stdlib=libc++ -MT libglog_la-logging.lo -MD -MP >> -MF >>> .deps/libglog_la-logging.Tpo -c src/logging.cc -fno-common -DPIC -o >>> libglog_la-logging.o >>> In file included from src/logging.cc:32: >>> In file included from ./src/utilities.h:75: >>> /usr/include/c++/v1/string:1953:10: error: object of type >>> 'std::__1::__compressed_pair<std::__1::basic_string<char, >>> std::__1::char_traits<char>, std::__1::allocator<char> >>>> ::__rep, std::__1::allocator<char> >' cannot be assigned because >>> its copy assignment operator is implicitly deleted >>> __r_ = _STD::move(__str.__r_); >>> ^ >>> /usr/include/c++/v1/string:1943:9: note: in instantiation of member >>> function 'std::__1::basic_string<char, std::__1::char_traits<char>, >>> std::__1::allocator<char> >>>> ::__move_assign' requested here >>> __move_assign(__str, true_type()); >>> ^ >>> /usr/include/c++/v1/string:1962:5: note: in instantiation of member >>> function 'std::__1::basic_string<char, std::__1::char_traits<char>, >>> std::__1::allocator<char> >>>> ::__move_assign' requested here >>> __move_assign(__str, integral_constant<bool, >>> ^ >>> src/logging.cc:886:27: note: in instantiation of member function >>> 'std::__1::basic_string<char, std::__1::char_traits<char>, >>> std::__1::allocator<char> >::operator=' >>> requested here >>> if ( slash ) linkpath = string(filename, slash-filename+1); // get >>> dirname >>> ^ >>> /usr/include/c++/v1/memory:1942:5: note: copy assignment operator is >>> implicitly deleted because >> '__compressed_pair<std::__1::basic_string<char, >>> std::__1::char_traits<char>, >>> std::__1::allocator<char> >::__rep, std::__1::allocator<char> >' >> has >>> a user-declared move constructor >>> __compressed_pair(__compressed_pair&& __p) >>> ^ >>> 1 error generated. >>> >>> >>> >>> >>> On Mon, Dec 30, 2013 at 8:22 PM, Benjamin Hindman < >>> [email protected]> wrote: >>> >>>> As a clarification, on OS X 10.9 (Mavericks) you should only need to do: >>>> >>>> $ ./bootstrap >>>> $ mkdir build && cd build >>>> $ ../configure && make check >>>> >>>> Also, I wanted to give a big shout out to Till Toenshoff for all the >> early >>>> investigative work on getting Mesos to build with clang >>>> (MESOS-860<https://issues.apache.org/jira/browse/MESOS-860>, >>>> MESOS-863 <https://issues.apache.org/jira/browse/MESOS-863>, >>>> MESOS-864<https://issues.apache.org/jira/browse/MESOS-864> >>>> )! >>>> >>>> >>>> On Mon, Dec 30, 2013 at 3:41 PM, Benjamin Hindman < >>>> [email protected]> wrote: >>>> >>>>> As many of you know, OS X 10.9 (Mavericks) made clang the default >>>> compiler >>>>> which broke Mesos. We had a couple of options: >>>>> >>>>> (1) Install and use gcc instead. >>>>> (2) Get Mesos to build with clang. >>>>> >>>>> Unfortunately, (1) wasn't sufficient because there were issues with >>>>> linking clang built libraries with gcc ones, especially for our Python >>>>> bindings. Doing (2) was also a non-starter because libprocess (the >>>>> concurrency library Mesos uses) had hard dependencies on gcc (or more >>>>> precisely on libstdc++). Our intuition was that the best way to >>>> eliminate >>>>> those dependencies was to refactor the libprocess code to use C++11, >> and >>>>> then build Mesos using clang with C++11. >>>>> >>>>> To that end I've pushed a branch at >>>>> https://github.com/benh/mesos/tree/c++11-and-clang that has 14 >> commits >>>>> enabling first C++11 in Mesos (and libprocess, and stout) and then >> C++11 >>>>> with clang. I've thus far tested this on OS X 10.7 with gcc 4.2.1 (no >>>>> C++11), gcc 4.8 (with C++11), and clang 3.3 (with C++11, in fact, we >>>> force >>>>> clang to build with C++11). I'd love to get others trying it out! Note >>>> that >>>>> we don't expect to support earlier versions of gcc or clang for C++11. >>>>> >>>>> You can compile with clang via: >>>>> >>>>> CC=/path/to/clang-3.3 CXX=/path/to/clang++-3.3 ../configure && make >>>> check >>>>> >>>>> And via gcc 4.8 for C++11: >>>>> >>>>> CC=/path/to/gcc-4.8 CXX=/path/to/g++-4.8 ../configure --with-cxx11 >> && >>>>> make check >>>>> >>>>> At this point in time on OS X if you use a non-LLVM wrapped gcc (i.e., >>>> the >>>>> non-default gcc) you can't build Python unless you've built you're own >>>>> Python using the same compiler you're using for Mesos (since some >>>> compiler >>>>> options might not be valid for non-LLVM wrapped compilers). You can >>>> disable >>>>> Python via --disable-python (which is necessary for me using gcc 4.8 >>>>> because I didn't build Python with gcc 4.8). >>>>> >>>>> The changes necessary did involve upgrading the embedded third party >>>>> ZooKeeper dependency as well as adding a patch to the embedded glog >>>>> dependency. In the long run, the goal is to eliminate the embedded >>>>> dependencies all together. In the short-term, however, we wanted to >>>> unblock >>>>> people using Mesos on OS X for development and testing. The updates >>>> should >>>>> not have any negative impact on building Mesos without the embedded >>>>> libraries (if anything, this should help since some distributions >>>> required >>>>> Mesos to build against ZooKeeper 3.4.5) and until we have a glog >>>>> distribution that works with clang/C++11 we'll likely need to >> compromise >>>>> and keep the glog library and patch embedded but only for building on >>>> OS X. >>>>> >>>>> As laid out in https://issues.apache.org/jira/browse/MESOS-750 we'll >> be >>>>> moving to "phase 3" after this code gets committed where we'll >> continue >>>> to >>>>> support both C++03 and C++11 compilers for at least another release >> (or >>>>> two) of Mesos. >>>>> >>>>> Looking forward to feedback. Happy New Year! >>>>> >>>>> Ben. >>>>> >>>> >>> >>> >>
