py26-numpy 1.4.1 undefined symbols in lapack_litemodule

[anddam (Andrea D'Amore)]

While upgrading py26-numpy 1.4.1 mp gets a lot of undefined symbols, here's an excerpt:

creating build/temp.macosx-10.6-x86_64-2.6/numpy/linalg
compile options: '-DATLAS_INFO="\"3.8.3\"" -I/opt/local/include -Inumpy/core/include -Ibuild/src.macosx-10.6-x86_64-2.6/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -Ibuild/src.macosx-10.6-x86_64-2.6/numpy/core/src/multiarray -Ibuild/src.macosx-10.6-x86_64-2.6/numpy/core/src/umath -c'
gcc-mp-4.3: numpy/linalg/python_xerbla.c
gcc-mp-4.3: numpy/linalg/lapack_litemodule.c
/opt/local/bin/gfortran -Wall build/temp.macosx-10.6-x86_64-2.6/numpy/linalg/lapack_litemodule.o build/temp.macosx-10.6-x86_64-2.6/numpy/linalg/python_xerbla.o -L/opt/local/lib -L/opt/local/lib/gcc43/gcc/x86_64-apple-darwin10/4.3.4 -Lbuild/temp.macosx-10.6-x86_64-2.6 -llapack -lptf77blas -lptcblas -latlas -lgfortran -o build/lib.macosx-10.6-x86_64-2.6/numpy/linalg/lapack_lite.so
Undefined symbols:
  "_PyExc_ValueError", referenced from:
      _xerbla_ in python_xerbla.o
  "_PyDict_SetItemString", referenced from:
      _initlapack_lite in lapack_litemodule.o
  "_PyErr_Print", referenced from:
      _initlapack_lite in lapack_litemodule.o
  "_Py_InitModule4_64", referenced from:
      _initlapack_lite in lapack_litemodule.o
  "_PyType_IsSubtype", referenced from:
      _check_object in lapack_litemodule.o
  "_PyModule_GetDict", referenced from:
      _initlapack_lite in lapack_litemodule.o
  "_PyArg_ParseTuple", 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

The problem seems to be related to atlas, variant '+no_atlas' installs succesfully with both apple gcc 4.2 and mp gcc43.

Using the atlas port the build fails with different error output according to use of +no_gcc43 variant, missing symbols are the same but each symbols is referred much many times.

I'm attaching debug output for numpy build without any variants.

[Veence (Vincent)]

You lack a link with the python26 library found in ${prefix}/lib

[Veence (Vincent)]

Please see #19397. I've posted a Portfile that allows universal build and also fixes this problem (and the same in scipy)

[anddam (Andrea D'Amore)]

Thanks vince, I added chmod for the wrapper files.

[skymoo (Adam Mercer)]

Cc Me!

[skymoo (Adam Mercer)]

does the solution proposed in #19397 fix this issue?

[ajb78@…]

Please also see the discussion in #26360.

[michaelld (Michael Dickens)]

Cc Me!

[michaelld (Michael Dickens)]

The fix, for me, is to remove all of the GCC variants (so lines 44-47) and thus change the command to "sudo port install py26-numpy [+universal]". This is one of possibly a few math-oriented ports that do not directly require linking to libgcc or libgfortran, so removing those variants should be safe.

I would encourage those on this ticket to try out this fix & see if it works for them, with and without +universal if possible.

[skymoo (Adam Mercer)]

upstream numpy told me that linking against atlas and not specifying a fortran compiler can cause problems, so take care with this approach.

[marshall.ward@…]

Cc Me!

[josharian@…]

Cc Me!

[michaelld (Michael Dickens)]

Hmm .. I tried what another person with this issue wrote (default Portfile with -gcc44) and it errors out the same for the rest of this ticket. So, I'm attaching a patch file (goes into .../python/py26-numpy/files ) as well as a Portfile diff -- it just adds this new file to the list of patches applied to the source (no matter what).

The issue is that LDFLAGS exists in the environment used to setup the linalg module, overriding the default values "-undefined dynamic_lookup -bundle". Without those values, the build errors out due to undefined symbols from -lpython. Since loading happens inside Python, these symbols already exist in the process, and hence are not necessary for linking the module. The source code patch just adds these flags to the linking of the linalg library.

If you want to try out these patches, download them from this ticket & then follow this "script" which will keep the old Portfile around for easy restoring. I'll assume you've downloaded the files to ~/Desktop, so change this directory as need be:

sudo port clean py26-numpy
cd `port dir py26-numpy`
sudo cp ~/Desktop/patch-numpy_linalg_setup.py.diff files
sudo cp Portfile Portfile_orig
sudo patch -p0 < ~/Desktop/py26-numpy_Portfile.diff
sudo port -d build py26-numpy -gcc44

and see if that works. You can also try "-gcc44 +universal" if your MP setup can do universal.

To restore everything back to normal, do:

cd `port dir py26-numpy`
sudo rm files/patch-numpy_linalg_setup.py.diff
sudo rm Portfile
sudo mv Portfile_orig Portfile

NOTE: This patch is for this ticket's issue only, by bypassing the use of gcc4X. This practice is not recommended by numpy upstream when using +atlas because atlas is compiled with gcc4X -- but it does seem to work. If the above works for you, please finish the install then go and try a Python program that uses numpy to see if it works for you.

[michaelld (Michael Dickens)]

Numpy source patch to add correct LDFLAGS to linalg module link command.

[michaelld (Michael Dickens)]

py26 numpy Portfile patch to add patchfile to list to use.

[jmroot (Joshua Root)]

If the problem is just that LDFLAGS is set, then turning off python.add_archflags will do the trick. (May or may not then need to set up some environment variables "manually".) That setting is on by default because most python modules will append CFLAGS/LDFLAGS/etc specified in the environment to their defaults rather than overwriting them.

[jmroot (Joshua Root)]

Oh, and why is /opt/local/bin/gfortran being used? That doesn't exist unless the user has installed and run gcc_select. It should be using ${configure.fc} (or f77/f90), e.g. ${prefix}/bin/gfortran-mp-4.4.

[michaelld (Michael Dickens)]

LDFLAGS contains the "-arch xxx" or "-mXX" arch specification; setting "python.add_archflags no" only changes this variable for the configure stage. Python ports using setup.py scripts require it to be set for the build stage, so changing this setting will at best allow for single architecture compilation; it will not solve the +universal install issues.

Further: For non-universal installs using the default compile architecture (which is the default, I think, for most ports), not setting LDFLAGS should work just fine & this patch isn't necessary (but it also does no harm). But, when compiling as +universal for the non-default architecture LDFLAGS must be set unless the arch flag is appended to the compiler info (e.g., CC=".../gcc-mp-4.4 -arch i386 -arch x86_64" if using Apple's GCC) -- and doing so has its own issue (try it and see for yourselves).

[michaelld (Michael Dickens)]

"/opt/local/bin/gfortran" is being used because no fortran compiler shell environment variable is being set (F77, F90, others), so numpy's setup.py script is going off and seeing what it can find. numpy will look for '[g]fortran[-mp][-X[.Y]]' and other names. If some fortran is found, it will be used to link in the linalg module only; if not, then the linking is reverted back to Apple's GCC. One can get around this issue by setting F77=${configure.fc} in build.env, or, in the case of numpy since these modules require only indirect GCC library linking, we could use F77=/usr/bin/gcc (or whatever MP's name for that compiler is). Setting F77 would at least partially take care of a couple tickets (e.g., #26419) where numpy finds '/usr/bin/gfortran', so it is a good idea.

[michaelld (Michael Dickens)]

Ideally, upstream would modify whatever part of setup.py is handling the LDFLAGS for the linalg module so that if LDFLAGS is set externally, these values are appended rather than overwriting the default values. But, that might be a whole new can of worms. My patch to linalg's setup.py script effectively does just that; it works (at least for me), but it's maybe not the best solution (e.g., if LDFLAGS is not set, then the flags in my parth are there twice -- which the compiler handles just fine but it just seems sloppy).

[sean@…]

Cc Me!

[michaelld (Michael Dickens)]

"svn diff" in py26-numpy port directory

[michaelld (Michael Dickens)]

I've attached a "svn diff" from the py26-numpy directory that, for me, takes care of about 10 tickets related to this topic (and probably some related to py2[57]-numpy as well). It uses Apple's GCC for CC related compiling and linking, and a GCC4X port's fortran for F90 related compiling and linking but only if using +atlas variant -- following the build guide provided by numpy developers. It allows one to specify -atlas (instead of +no_atlas) and thus remove the GCC4X port dependency entirely. Further, it restricts the fortran executable to that provided in the Portfile, so that spurious versions are not found and used. Can others please test out these patches to verify them? Remember to clean up the py26-numpy directory first (revert any files).

[skymoo (Adam Mercer)]

The patch looks good after a quick look, I'm travelling until next week so won't have till chance to take a proper look until Monday at the earliest. If you haven't heard anything from me by next Wednesday give me a kick.

[dbevans (David B. Evans)]

Looks good here so far. Have built the following successfully on SL x86_64 and the non-universal pair on Leopard ppc with no problems. Universal variants on Leopard are in progress but its a much slower machine.

  py26-numpy @1.5.0_1 (-atlas)
  py26-numpy @1.5.0_1+atlas+gcc44
  py26-numpy @1.5.0_1+atlas+gcc44+universal (active)
  py26-numpy @1.5.0_1+universal (-atlas)

[marshall.ward@…]

The patch worked for me. I can built 1.5.0 with atlas now, without any issues.

[anddam (Andrea D'Amore)]

Replying to michaelld@…:

Can others please test out these patches to verify them?

Seems to work fine for me:

$ port -v installed py26-numpy
The following ports are currently installed:
  py26-numpy @1.5.0_0+gcc44 platform='darwin 10' archs='x86_64'
  py26-numpy @1.5.0_1+atlas+gcc44 (active) platform='darwin 10' archs='x86_64'

[josharian@…]

Replying to michaelld@…:

Can others please test out these patches to verify them?

Worked like a charm, everything functions as it should. Awesome -- thank you!

[josharian@…]

Replying to josharian@…:

Worked like a charm, everything functions as it should. Awesome -- thank you!

Ah, sorry, should have mentioned for coverage purposes:

port -v installed py26-numpy
The following ports are currently installed:
  py26-numpy @1.4.1_1+gcc44 platform='darwin 10' archs='x86_64'
  py26-numpy @1.5.0_1+atlas+gcc44 (active) platform='darwin 10' archs='x86_64'

[hugo.strand@…]

Replying to michaelld@…:

Can others please test out these patches to verify them?

Works for me with +gcc44 and +atlas. Thanks!

[jmroot (Joshua Root)]

Replying to michaelld@…:

setting "python.add_archflags no" only changes this variable for the configure stage.

That's incorrect.

[michaelld (Michael Dickens)]

Replying to jmr@…:

Replying to michaelld@…:

setting "python.add_archflags no" only changes this variable for the configure stage.

That's incorrect.

I realized that after the fact, and the latest diffs reflect this change. Sorry for the confusion; it's a learning curve :)

[hobbsilla]

adding python.add_archflags no also prevents avahi from being able to build however.

[hobbsilla]

Cc Me!

[ajb78@…]

I managed to compile it with +gcc44 and +atlas. Everything seemed to be fine, however, f2py cannot find a fortran compiler after the install.

[skymoo (Adam Mercer)]

Finally got round to taking a look at this, it works for me and the test suite passes. I am happy with this being pushed. But we'd also need to ensure that the py25 and py27 versions are also updated accordingly.

[hugo.strand@…]

I've also managed to install the py26-numpy +atlas +gcc44 using the submitted patch. But have the same problem as ajb78 that f2py does not find any fortran compiler after the install. This is due to the new Portfile setting the F90=/opt/local/bin/gfortran-mp-X.X environment variable when building Numpy which does not stick after the installation.

A not satisfactory fix is to manually set the F90 environment variable if you want to build anything else using f2py.

[michaelld (Michael Dickens)]

I'm pretty sure I know the f2py issue; I'll be looking into it this morning. I've tested this fix with py27-numpy and it performs the same (with the same f2py issue). So, we're almost there.

[michaelld (Michael Dickens)]

"svn diff" in py26-numpy port directory; should fix F2PY script finding fortran.

[michaelld (Michael Dickens)]

"svn diff" in py26-numpy port directory; should fix F2PY script finding fortran.

[michaelld (Michael Dickens)]

I just uploaded YA 'svn diff' of the py26-numpy Portfile & files. You'll need to restore to SVN before applying this diff; please do check it out & make sure it works for your setup (it does for me: 10.6.4 x86_64, port from svn, XCode 3.2.3). After installing, do:

$ python
>>> import numpy
>>> numpy.test('1','10')

and the end result should be something like:

FAILED (KNOWNFAIL=4, SKIP=15, errors=2)
<nose.result.TextTestResult run=2623 errors=2 failures=0>

with the 2 errors being for not being able to import "multiarray" and "testing" (this is normal).

This (hopefully final) change forces the F2PY script to look for the specific version of F90 (e.g., "gfortran-mp-4.4") if it is set instead of generic names ("gfortran", "g77", "g95"). If -atlas is specified, then the F2PY script is not changed & may or not find an appropriate fortran to use. This is a trade-off (TANSTAAFL) that has to be made when not requiring +gcc4X to be installed -- there may or not be a usable fortran compiler available.

[anddam (Andrea D'Amore)]

Here's my setup with py26-numpy_svn_2.2.diff patch:

$ xcodebuild -version | head -n 1
Xcode 3.2.3
$ python_select -s
python26
$ port -v installed py26-numpy
The following ports are currently installed:
  py26-numpy @1.5.0_1+atlas+gcc44 (active) platform='darwin 10' archs='x86_64'

Replying to michaelld@…:

with the 2 errors being for not being able to import "multiarray" and "testing" (this is normal).

Seems I'm slightly overperforming you:

OK (KNOWNFAIL=4, SKIP=1)
<nose.result.TextTestResult run=2979 errors=0 failures=0>

;-)

[nilstec_inc@…]

Cc Me!

[jabronson@…]

Cc Me!

[michaelld (Michael Dickens)]

I've checked in the changes in r72220; please do:

sudo port clean py26-numpy
sudo port selfupdate
sudo port install py26-numpy [+variants]

and see if it works. I'm closing this ticket as fixed; please reopen if the changes do not work for you.

[nilstec_inc@…]

It works! Thank you very very much for your effort! :)