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.
> >> >
> >>
> >
> >
>

Reply via email to