BUG: py-scipy 0.5.2 fails to build on an intel mac (swig fails trying to find UMFPACK headers)

[c.khroulev@…]

py-scipy fails to build on an Intel Mac with the following error message:

constantine-khroulevs-computer:~ constantine$ sudo port install py-scipy
--->  Fetching py-scipy
--->  Attempting to fetch scipy-0.5.2.tar.gz from http://downloads.sourceforge.net/scipy
--->  Verifying checksum(s) for py-scipy
--->  Extracting py-scipy
--->  Applying patches to py-scipy
--->  Configuring py-scipy
--->  Building py-scipy with target build
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-scipy/work/scipy-0.5.2" && /opt/local/bin/python2.4 setup.py build " returned error 1
Command output: building extension "scipy.linsolve._zsuperlu" sources
building extension "scipy.linsolve._dsuperlu" sources
building extension "scipy.linsolve._csuperlu" sources
building extension "scipy.linsolve._ssuperlu" sources
building extension "scipy.linsolve.umfpack.__umfpack" sources
creating build/src.macosx-10.3-i386-2.4/scipy/linsolve
creating build/src.macosx-10.3-i386-2.4/scipy/linsolve/umfpack
  adding 'Lib/linsolve/umfpack/umfpack.i' to sources.
creating build/src.macosx-10.3-i386-2.4/Lib/linsolve
creating build/src.macosx-10.3-i386-2.4/Lib/linsolve/umfpack
swig: Lib/linsolve/umfpack/umfpack.i
swig -python -o build/src.macosx-10.3-i386-2.4/Lib/linsolve/umfpack/_umfpack_wrap.c -outdir build/src.macosx-10.3-i386-2.4/Lib/linsolve/umfpack Lib/linsolve/umfpack/umfpack.i
Lib/linsolve/umfpack/umfpack.i:188: Error: Unable to find 'umfpack.h'
Lib/linsolve/umfpack/umfpack.i:189: Error: Unable to find 'umfpack_solve.h'
Lib/linsolve/umfpack/umfpack.i:190: Error: Unable to find 'umfpack_defaults.h'
Lib/linsolve/umfpack/umfpack.i:191: Error: Unable to find 'umfpack_triplet_to_col.h'
Lib/linsolve/umfpack/umfpack.i:192: Error: Unable to find 'umfpack_col_to_triplet.h'
Lib/linsolve/umfpack/umfpack.i:193: Error: Unable to find 'umfpack_transpose.h'
Lib/linsolve/umfpack/umfpack.i:194: Error: Unable to find 'umfpack_scale.h'
Lib/linsolve/umfpack/umfpack.i:196: Error: Unable to find 'umfpack_report_symbolic.h'
Lib/linsolve/umfpack/umfpack.i:197: Error: Unable to find 'umfpack_report_numeric.h'
Lib/linsolve/umfpack/umfpack.i:198: Error: Unable to find 'umfpack_report_info.h'
Lib/linsolve/umfpack/umfpack.i:199: Error: Unable to find 'umfpack_report_control.h'
Lib/linsolve/umfpack/umfpack.i:211: Error: Unable to find 'umfpack_symbolic.h'
Lib/linsolve/umfpack/umfpack.i:212: Error: Unable to find 'umfpack_numeric.h'
Lib/linsolve/umfpack/umfpack.i:221: Error: Unable to find 'umfpack_free_symbolic.h'
Lib/linsolve/umfpack/umfpack.i:222: Error: Unable to find 'umfpack_free_numeric.h'
Lib/linsolve/umfpack/umfpack.i:244: Error: Unable to find 'umfpack_get_lunz.h'
Lib/linsolve/umfpack/umfpack.i:268: Error: Unable to find 'umfpack_get_numeric.h'
error: command 'swig' failed with exit status 1

Error: Status 1 encountered during processing.

This is the same error as reported in the ticket 11912; these symptoms reappeared after the py-numpy upgrade. (It failed with a different message before, see the ticket 11912.)

I opened this bug again (as requested by erickt@…), since I do have problems still...

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

A relatively easy (but ugly) solution is to modify umfpack.i (see attached file).

[erickt@…]

So scipy has been bumped to version 0.6.0, does that fix the bug?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I personally use py25-scipy 0.60, and it is still unable to find the UMFPACK headers.

[skymoo (Adam Mercer)]

Is this still you the problem?

[c.khroulev@…]

I tried it today, and here are the results: 1) py-numpy fails to build using the default variant (g95). Builds fine with +gcc42 2) py-scipy builds fine both with +g95 and +gcc42, but works only if built with +gcc42 (otherwise it can't use NumPy, I suppose).

I do have problems building py25-scipy 0.6.0, though. py25-hashlib fails to build with the following message:

--->  Building py25-hashlib with target build
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py25-hashlib/work/Python-2.5.1/Modules" && /opt/local/bin/python2.5 setup.py build " returned error 1
Command output: running build
running build_ext
building '_hashlib' extension
creating build
creating build/temp.macosx-10.3-i386-2.5
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/opt/local/include -I/opt/local/include/python2.5 -c _hashopenssl.c -o build/temp.macosx-10.3-i386-2.5/_hashopenssl.o
unable to execute -DNDEBUG: No such file or directory
error: command '-DNDEBUG' failed with exit status 1

Looks like this is a known issue (although I couldn't find a ticket describing it). Apparently, (​http://www.nabble.com/py25-hashlib-failing-on-build-td15259189.html) py25-tkinter fails the same way...

So, I think this ticket should be closed.

[skymoo (Adam Mercer)]

1. What's the error that py-numpy +g95 fails with?
2. Does py25-numpy +g95 fail with the same error?

I've seen the error above that you get from py25-hashlib, it seems to be a temporary error (at least for me) try building it again.

[skymoo (Adam Mercer)]

Another question, is this Tiger? Intel?

[c.khroulev@…]

Whoops. py-numpy built just fine with +g95 this time. (I'm not sure what helped; maybe a "port sync"?...)

The error I got earlier is

--->  Building py-numpy with target build
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-numpy/work/numpy-1.0.4" && /opt/local/bin/python2.4 setup.py config_fc --fcompiler g95 --f77exec /opt/local/bin/g95 --f90exec /opt/local/bin/g95 build " returned error 1
Command output: Traceback (most recent call last):
  File "setup.py", line 89, in ?
    setup_package()
  File "setup.py", line 82, in setup_package
    configuration=configuration )
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-numpy/work/numpy-1.0.4/numpy/distutils/core.py", line 176, in setup
    return old_setup(**new_attr)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 946, in run_commands
    self.run_command(cmd)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 966, in run_command
    cmd_obj.run()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/command/build.py", line 112, in run
    self.run_command(cmd_name)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 966, in run_command
    cmd_obj.run()
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-numpy/work/numpy-1.0.4/numpy/distutils/command/build_src.py", line 130, in run
    self.build_sources()
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-numpy/work/numpy-1.0.4/numpy/distutils/command/build_src.py", line 147, in build_sources
    self.build_extension_sources(ext)
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-numpy/work/numpy-1.0.4/numpy/distutils/command/build_src.py", line 250, in build_extension_sources
    sources = self.generate_sources(sources, ext)
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-numpy/work/numpy-1.0.4/numpy/distutils/command/build_src.py", line 307, in generate_sources
    source = func(extension, build_dir)
  File "numpy/core/setup.py", line 53, in generate_config_h
    raise SystemError,"Failed to test configuration. "\
SystemError: Failed to test configuration. See previous error messages for more information.

py25-numpy +g95 builds alright (you're right, the py25-hashlib error is temporary).

And, by the way, today py25-scipy built with no errors too! (Yay! :-) )

This is Leopard (10.5.2) on an Intel MacBook, XCode 3.0.

Now I only need to get octave to build, and I'll be as happy as a clam. :-) (octave depends on hdf5, hdfgroup switched to the version 1.8.0 recently, and the portfile isn't updated yet...)

[c.khroulev@…]

Another thing: py25-scipy should depend on py25-zlib.

(If py25-zlib if not installed, "from scipy import *" fails with

>>> from scipy import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python2.5/site-packages/scipy/io/__init__.py", line 11, in <module>
    from mio import *
  File "/opt/local/lib/python2.5/site-packages/scipy/io/mio.py", line 11, in <module>
    from scipy.io.mio5 import MatFile5Reader, MatFile5Writer
  File "/opt/local/lib/python2.5/site-packages/scipy/io/mio5.py", line 29, in <module>
    import zlib
ImportError: No module named zlib
}}})

[skymoo (Adam Mercer)]

Replying to c.khroulev@gmail.com:

Another thing: py25-scipy should depend on py25-zlib.

Thanks, fixed in r34214

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Sorry to reopen this Ticket, but without the patch file, I still get the same errors that were originally reported.
Perhaps it is not clear from the previous discussion, but SuiteSparse must be installed to get the error.

UMFPACK is both an independent package and part of SuiteSparse.
Once py25-scipy detects libumfpack.a, it looks for the corresponding include files.
The header setups in plain UMFPACK and SuiteSparse are different enough to cause problems.
The previously submitted patch works around this by changing some "#include" statements in the umfpack.i file.

The other problems that were included in this Ticket seem to have been fixed, but I believe the origional problem is still unresolved.

Could I please be added to Cc?

[skymoo (Adam Mercer)]

Whats the platform?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Mac OS 10.5.2 (Leopard ) on an intel processor.
All the most recent MacPorts updates.

[skymoo (Adam Mercer)]

Same platform as me and it builds without issue for me. Is this with only py25-scipy or do you get the same error with py-scipy as well?

[skymoo (Adam Mercer)]

Another question, do you get this error with all the different fortran variants?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I get the exact same error with py-scipy.
I get the same error with both the g95 and gcc43 variants (I don't have gcc42 installed).

Just to clarify, can others get it to work even with SuiteSparse installed?

[skymoo (Adam Mercer)]

patched in r35847, thanks

[skymoo (Adam Mercer)]

Replying to marcuscalhounlopez@mac.com:

Just to clarify, can others get it to work even with SuiteSparse installed?

I couldn't originally but can now, SuiteSparse was installed but not active, the change in r35847 fixes it for me.

[(none)]

Milestone Port Bugs deleted