py25-numpy and py26-numpy 1.4.1 upgrade fails

[dersh@…]

Seems that both py25-numpy and py26-numpy were just upgraded to 1.4.1_0.

I am getting a similar link error trying to do both upgrades, so I figured I would put both into the same ticket.

sudo port upgrade py25-numpy
--->  Computing dependencies for py25-numpy
--->  Building py25-numpy
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-numpy/work/numpy-1.4.1" && /opt/local/bin/python2.5 setup.py --no-user-cfg build " returned error 1
Command output:       _initlapack_lite in lapack_litemodule.o
  "_PyCObject_Type", referenced from:
      _initlapack_lite in lapack_litemodule.o
  "_PyType_IsSubtype", referenced from:
      _check_object in lapack_litemodule.o
  "_Py_BuildValue", referenced from:
      _lapack_lite_zungqr in lapack_litemodule.o
      _lapack_lite_zgeqrf in lapack_litemodule.o
      _lapack_lite_zpotrf in lapack_litemodule.o
      _lapack_lite_zgetrf in lapack_litemodule.o
      _lapack_lite_zgesdd in lapack_litemodule.o
      _lapack_lite_zgesv in lapack_litemodule.o
      _lapack_lite_zgelsd in lapack_litemodule.o
      _lapack_lite_zgeev in lapack_litemodule.o
      _lapack_lite_dorgqr in lapack_litemodule.o
      _lapack_lite_dgeqrf in lapack_litemodule.o
      _lapack_lite_dpotrf in lapack_litemodule.o
      _lapack_lite_dgetrf in lapack_litemodule.o
      _lapack_lite_dgesdd in lapack_litemodule.o
      _lapack_lite_dgesv in lapack_litemodule.o
      _lapack_lite_dgelsd in lapack_litemodule.o
      _lapack_lite_dgeev in lapack_litemodule.o
      _lapack_lite_dsyevd in lapack_litemodule.o
      _lapack_lite_zheevd in lapack_litemodule.o
  "_PyModule_GetDict", referenced from:
      _initlapack_lite in lapack_litemodule.o
  "_PyCObject_AsVoidPtr", referenced from:
      _initlapack_lite in lapack_litemodule.o
ld: symbol(s) not found
error: Command "/opt/local/bin/g95 -shared -shared build/temp.macosx-10.6-i386-2.5/numpy/linalg/lapack_litemodule.o build/temp.macosx-10.6-i386-2.5/numpy/linalg/python_xerbla.o -L/opt/local/lib -Lbuild/temp.macosx-10.6-i386-2.5 -llapack -lptf77blas -lptcblas -latlas -o build/lib.macosx-10.6-i386-2.5/numpy/linalg/lapack_lite.so" failed with exit status 1

Error: Unable to upgrade port: 1
Before reporting a bug, first run the command again with the -d flag to get complete output.

It looks like some dependencies is not being found.

Thanks,

--Adam

[ram@…]

 error: Command "/opt/local/bin/g95 -shared -shared

g95 is not supported by numpy distutils on Mac OS X, so it shouldn't be using this fortran compiler. Can you attach the full debug log?

sudo port clean py26-numpy
sudo port -d install py26-numpy 2>&1 | tee ~/Desktop/py26-numpy.txt

[dersh@…]

Full debug info

[dersh@…]

I attached the log, as requested. But, for what it is worth, I have had g95 around for a while (although it did recently upgrade). But I have not set any variants for the numpy builds. So it looks like something changed in the numpy port so that it now finds g95.

[ram@…]

OK, I think I know what the problem is. I've attached a patch which _should_ fix the problem (I hope).

$ cd `port dir py26-numpy`
$ patch -p0 < /path/to/numpy.diff

then try rebuilding.

[dersh@…]

Nope. Now I get this error:

sudo port -d upgrade py26-numpy
DEBUG: Found port in file:///opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py26-numpy
DEBUG: epoch: in tree: 20100319 installed: 20100319
DEBUG: py26-numpy 1.4.1_0 exists in the ports tree
DEBUG: py26-numpy 1.3.0_0  is the latest installed
DEBUG: py26-numpy 1.4.0_0  is active
DEBUG: Merging existing variants  into variants
DEBUG: new fully merged portvariants: 
DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py26-numpy
DEBUG: OS Platform: darwin
DEBUG: OS Version: 10.3.0
DEBUG: Mac OS X Version: 10.6
DEBUG: System Arch: i386
DEBUG: setting option os.universal_supported to yes
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: Using group file /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python26-1.0.tcl
DEBUG: can't read "config_options": no such variable
    while executing
"build.cmd-append        ${fc_options} ${config_options}"
    invoked from within
"if {![variant_isset no_gcc43]} {
    configure.compiler      macports-gcc-4.3
    set fc_options          "config_fc --fcompiler gnu95 --f77exec ${pre..."
    (file "Portfile" line 32)
    invoked from within
"source Portfile"
    invoked from within
"$workername eval source Portfile"
    (procedure "mportopen" line 46)
    invoked from within
"mportopen $porturl [array get options] [array get variations]"
Error: Unable to open port: can't read "config_options": no such variable
To report a bug, see <http://guide.macports.org/#project.tickets>

[ram@…]

Damn, I've attached an updated version. Or just remove the ${config_options} from the build.cmd-append and destroot.cmd-append lines.

[dersh@…]

That did the job. Thanks. Are you going to update the port, to apply that to both py25 and py26 numpy?

[ram@…]

Great. I'll try and get both py25-numpy and py26-numpy updated this evening.

[ram@…]

I think I've got a different fix, which I think is the correct approach in this case. As G95 is not supported by NumPy distutils, this patch (py26-numpy_g95.patch) removes G95 from the list of fortran compilers to search for. I am unable to duplicate the problem after applying this patch.

$ cd `port dir py26-numpy`
$ patch -p3 < /path/to/py26-numpy_g95.patch

This is against the Portfile from the repository, so you'll need to undo the application of that last patch.

[dersh@…]

I did sudo port sync, which I think restored the Portfile to the one from the server. Then I did an uninstall of 1.4.1_0, clean, applied the new patch and did an upgrade, and it seemed to install fine. So I think that this solves the problem.

Thanks,

[ram@…]

committed in r66966