On Apr 19, 2014, at 7:44 PM, Even Rouault <even.roua...@mines-paris.org> wrote:
> Selon William Kyngesburye <wokl...@kyngchaos.com>: > >> On Apr 19, 2014, at 2:56 PM, Even Rouault <even.roua...@mines-paris.org> >> wrote: >> >>> Le samedi 19 avril 2014 21:19:53, William Kyngesburye a écrit : >>>> It looks like a bit of a coordination and packaging snafu with Apple. >>>> Apple builds Python with some old flags that clang doesn't support, but >>>> clang defaulted to NOT reporting the unknown flag as error. The recent >>>> clang 5.1 changed this default to error. >>>> >>>> I found a discussion about it on stackoverflow: >>>> >>>> >> http://stackoverflow.com/questions/22313407/clang-error-unknown-argument-mn >>>> o-fused-madd-python-package-installation-fa >>>> >>>> The -Qunused-arguments trick seems to work for some and not others. There >>>> is another method to try (the error actually mentions it): add this to >>>> ARCHFLAGS: >>>> >>>> -Wno-error=unused-command-line-argument-hard-error-in-future >>> >>> I've not access to a Mac myself, only through Travis, which is highly >>> inconvenient for trial and error attempts. Perhaps you or someone with >> direct >>> access to a system that exhibits the issue can come up with a patch ? >>> >> >> The ARCHFLAGS method worked for me. >> >> Configure looks at ARCHFLAGS from the ENV, and it adds it to all compilation >> just like CFLAGS. >> >> But python distutils will only see it if set in the ENV, before configure. >> If set inline with configure command (ie configure .... ARCHFLAGS=), it >> doesn't get added to python compilation. >> >> Adding it inline with the make command sets it in the environment so that >> only python compilation sees it, which may best so that it doesn't hide other >> unknown flag errors in general compilation that may need to be fixed (ie find >> alternatives). > > Based on your above hint, I've tried the following changeset > http://trac.osgeo.org/gdal/changeset/27225 but it doesn't work on Travis... > I'm not sure if the if branch is taken or not. And if it is taken is the > modified environmenet propagated to the child... (on Linux, it is...) > Well, you could try leaving out the os.uname test. clang is clang no matter what version of OS X, and it wouldn't hurt to include the option when it's already default. Also, testing the OS version doesn't necessarily say what clang version is installed. ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
