Hi,
On Thu, Jul 19, 2012 at 8:29 AM, Ralf Gommers
<ralf.gommers@googlemail.com> wrote:
>>> On Wed, Jul 18, 2012 at 9:49 PM, Matthew Brett <matthew.brett@gmail.com>
> wrote:
>>>> Hi,
>>>> Please forgive the half-baked question, but, I'm trying to build our
>> package nipy (nipy.org) against stock downloaded
>>>> numpy-1.6.2-py2.7-python.org-macosx10.6.dmg
>> scipy-0.10.1-py2.7-python.org-macosx10.6.dmg
>>> You're only building against numpy, and scipy is a runtime dependency,
> right?
Right - thanks for the clarification.
>>>> I'm using latest XCode 4.3.3
>>>> $ clang --version
>> Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)
>> Target: x86_64-apple-darwin11.4.0
>> Thread model: posix
>>>> on Lion:
>>>> $ uname -a
>> Darwin pis-macbook-air 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9
>> 19:33:05 PDT 2012; root:xnu-1699.26.8~1/RELEASE_I386 i386
>>>> I believe the correct incantation for the build is:
>>>>http://scipy.org/Installing_SciPy/Mac_OS_X>>>> CC=clang CXX=clang FFLAGS=-ff2c python setup.py build_ext -i
>>> It has been reported to work for scipy, that's as much as I know. You can
> try if building scipy in the same way works for you. If it doesn't, the
> problem may not be in nipy.
Having linked the http://r.research.att.com/tools/ gfortran-4.2 to
gfortran, this scipy build:
CC=clang FFLAGS=-ff2c python setup.py build_ext -i
builds and passes all tests.
Building and linking nipy with the same flags, and with this scipy on
the path, passes all tests.
Take this scipy off the path (reverting to the system scipy as
downloaded) gives another segfault in the same routine as before, but
a little later:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 _segmentation.so 0x00000001035eef14 _get_message_mf
+ 20 (mrf.c:59)
1 _segmentation.so 0x00000001035eebee ve_step + 798 (mrf.c:172)
2 _segmentation.so 0x00000001035ed4dc
__pyx_pf_4nipy_10algorithms_12segmentation_13_segmentation__ve_step +
4604 (_segmentation.c:1103)
3 org.python.python 0x00000001000c1e7d PyEval_EvalFrameEx + 25213
>> This does build, but during the tests, and only on this platform,
>> segfaults (report attached).
>>>> Is this build / link expected to work? Did I get the right flags?
>>> Not sure. Some things to check: that you have the 64-bit python from
> python.org, that MACOSX_DEPLOYMENT_TARGET is set to 10.6 during the build.
The MACOSX_DEPLOYMENT_TARGET did not seem to make a difference.
> The by far most reliable way to make everything work together is to use the
> exact same compiler. Which is not available anymore with the most recent
> XCode. You could look into ways to get gcc-4.2 to install on 10.7. And make
> sure to build your binaries on 10.6 for 64-bit 2.7 and on 10.5 for the other
> Python 2.x flavors if you can.
Hum. I had previously tried the R gcc-4.2 compiler (thanks Scott for
the link) and run into:
gcc-4.2: /Users/mb312/dev_trees/nipy/libcstat/wrapper/fffpy.c
In file included from
/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/unicodeobject.h:4,
from
/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:85,
from /Users/mb312/dev_trees/nipy/libcstat/wrapper/fffpy.h:1,
from /Users/mb312/dev_trees/nipy/libcstat/wrapper/fffpy.c:1:
/Developer/SDKs/MacOSX10.6.sdk/usr/include/stdarg.h:4:25: error:
stdarg.h: No such file or directory
Anything obvious that I missed?
Cheers,
Matthew