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 (toensh...@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.mah...@gmail.com> wrote: > Is there anything we can do to enforce this compatibility matrix at configure > time? > > ---------- Forwarded message ---------- > From: Till Toenshoff <toensh...@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 <vinodk...@gmail.com> wrote: > > > On Sat, Mar 8, 2014 at 6:23 PM, haja gecko <haja.ge...@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" * > > ➜ > >
