mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Till Toenshoff <toensh...@me.com>
Subject Re: building meso-0.17.0 failing on maverick
Date Mon, 10 Mar 2014 19:59:27 GMT
I believe that we are doing that since commit c3505e319d759e68425aa3b7177fc4377bf8db77 had
landed.

That patch should warn users during the configuration phase when invalid python / c++ compiler
setups are detected.

Haja, could you please send your config.log directly to me (toenshoff@me.com) as I missed
your original post and the archives seem to have removed your attachment.

On Mar 10, 2014, at 7:43 PM, Benjamin Mahler <benjamin.mahler@gmail.com> wrote:

> Is there anything we can do to enforce this compatibility matrix at configure time?
> 
> ---------- Forwarded message ----------
> From: Till Toenshoff <toenshoff@me.com>
> Date: Mon, Mar 10, 2014 at 11:38 AM
> Subject: Re: building meso-0.17.0 failing on maverick
> To: dev@mesos.apache.org
> 
> 
> Hey there - I did unfortunately miss the initial question, hence I have to do a bit of
guess-work here. Forgive me if that is entirely off.
> 
> 
> That flag is not explicitly set by Mesos, as Vinod mentioned. It is however implicitly
done by distutils extraction the cflags out of the existing python installation. So in the
end, Mesos does in fact use that flag at least for the Python egg compilation.
> 
> You can check that by running:
> python-config —cflags
> 
> I would expect something like the following as the result:
> 
> -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
-fno-strict-aliasing -fno-common -dynamic -arch x86_64 -arch i386 -g -Os -pipe -fno-common
-fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes
-Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE
> 
> 
> As you can see, there is this "-Wshorten-64-to-32” coming from and it is used when
building the python egg. As you are using gcc to compile and not clang, the problem pops up.
> 
> If you really have to use gcc, then you will have to install an alternative Python distribution
- I would recommend using homebrew or anything else.
> 
> As an alternative, use clang as that is AFAIK fully supported since Mesos 0.17.0.
> 
> The simplified compatibility matrix is as follows:
> 
>           apple-python  brew-python
> clang         X                    -
> gcc            -                     X
> 
> 
> Hope that helps. There is some more background on this issue on http://stackoverflow.com/questions/20733512/mesos-examplestest-pythonframework-check-fails-on-osx
> 
> cheerio!
> Till
> 
> On Mar 10, 2014, at 6:50 PM, Vinod Kone <vinodkone@gmail.com> wrote:
> 
> > On Sat, Mar 8, 2014 at 6:23 PM, haja gecko <haja.gecko@gmail.com> wrote:
> >
> >> gcc-4.8: error: unrecognized command line option '-Wshorten-64-to-32'
> >>
> >>
> > This doesn't seem to be a valid gcc option. AFAICT, this is not being set
> > in our Makefiles. Do you have some alias that is setting this option?
> >
> > ➜  mesos git:(master) gcc-4.8 -Wshorten-64-to-32
> > gcc-4.8: error: unrecognized command line option '-Wshorten-64-to-32'
> > gcc-4.8: fatal error: no input files
> > compilation terminated.
> >
> > ➜  mesos git:(master) ack "shorten-64-to-32" *
> > ➜
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message