Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#24942 closed defect (fixed)

py26-numpy 1.4.1 undefined symbols in lapack_litemodule

Reported by: anddam (Andrea D'Amore) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 1.9.99
Keywords: Cc: skymoo (Adam Mercer), michaelld (Michael Dickens), marshall.ward@…, josharian@…, sean@…, hobbsilla, nilstec_inc@…, jabronson@…
Port: py26-numpy

Description

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.

Attachments (7)

numpy-build-error.txt (187.0 KB) - added by anddam (Andrea D'Amore) 14 years ago.
Portfile_numpy (3.8 KB) - added by anddam (Andrea D'Amore) 14 years ago.
patch-numpy_linalg_setup.py.diff (506 bytes) - added by michaelld (Michael Dickens) 14 years ago.
Numpy source patch to add correct LDFLAGS to linalg module link command.
py26-numpy_Portfile.diff (510 bytes) - added by michaelld (Michael Dickens) 14 years ago.
py26 numpy Portfile patch to add patchfile to list to use.
py26-numpy_svn.diff (6.0 KB) - added by michaelld (Michael Dickens) 14 years ago.
"svn diff" in py26-numpy port directory
py26-numpy_svn_2.diff (6.5 KB) - added by michaelld (Michael Dickens) 14 years ago.
"svn diff" in py26-numpy port directory; should fix F2PY script finding fortran.
py26-numpy_svn_2.2.diff (6.4 KB) - added by michaelld (Michael Dickens) 14 years ago.
"svn diff" in py26-numpy port directory; should fix F2PY script finding fortran.

Download all attachments as: .zip

Change History (47)

Changed 14 years ago by anddam (Andrea D'Amore)

Attachment: numpy-build-error.txt added

comment:1 Changed 14 years ago by Veence (Vincent)

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

comment:2 Changed 14 years ago by Veence (Vincent)

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

Changed 14 years ago by anddam (Andrea D'Amore)

Attachment: Portfile_numpy added

comment:3 Changed 14 years ago by anddam (Andrea D'Amore)

Thanks vince, I added chmod for the wrapper files.

comment:4 Changed 14 years ago by skymoo (Adam Mercer)

Cc: ram@… added

Cc Me!

comment:5 Changed 14 years ago by skymoo (Adam Mercer)

does the solution proposed in #19397 fix this issue?

comment:6 Changed 14 years ago by ajb78@…

Please also see the discussion in #26360.

comment:7 Changed 14 years ago by michaelld (Michael Dickens)

Cc: michaelld@… added

Cc Me!

comment:8 Changed 14 years ago by 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.

comment:9 Changed 14 years ago by 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.

comment:10 Changed 14 years ago by marshall.ward@…

Cc: marshall.ward@… added

Cc Me!

comment:11 Changed 14 years ago by josharian@…

Cc: josharian@… added

Cc Me!

comment:12 Changed 14 years ago by 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.

Changed 14 years ago by michaelld (Michael Dickens)

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

Changed 14 years ago by michaelld (Michael Dickens)

Attachment: py26-numpy_Portfile.diff added

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

comment:13 Changed 14 years ago by 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.

comment:14 Changed 14 years ago by 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.

comment:15 Changed 14 years ago by 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).

comment:16 Changed 14 years ago by 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.

comment:17 Changed 14 years ago by 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).

comment:18 Changed 14 years ago by sean@…

Cc: sean@… added

Cc Me!

Changed 14 years ago by michaelld (Michael Dickens)

Attachment: py26-numpy_svn.diff added

"svn diff" in py26-numpy port directory

comment:19 Changed 14 years ago by 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).

comment:20 Changed 14 years ago by 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.

comment:21 Changed 14 years ago by 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)


comment:22 Changed 14 years ago by marshall.ward@…

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

comment:23 in reply to:  19 Changed 14 years ago by 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'

comment:24 in reply to:  19 ; Changed 14 years ago by 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!

comment:25 in reply to:  24 Changed 14 years ago by 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'

comment:26 in reply to:  19 Changed 14 years ago by hugo.strand@…

Replying to michaelld@…:

Can others please test out these patches to verify them?

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

comment:27 in reply to:  15 ; Changed 14 years ago by jmroot (Joshua Root)

Replying to michaelld@…:

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

That's incorrect.

comment:28 in reply to:  27 Changed 14 years ago by 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 :)

comment:29 Changed 14 years ago by hobbsilla

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

comment:30 Changed 14 years ago by hobbsilla

Cc: hobbsilla@… added

Cc Me!

comment:31 Changed 14 years ago by 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.

comment:32 Changed 14 years ago by 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.

comment:33 Changed 14 years ago by 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.

comment:34 Changed 14 years ago by 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.

Changed 14 years ago by michaelld (Michael Dickens)

Attachment: py26-numpy_svn_2.diff added

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

Changed 14 years ago by michaelld (Michael Dickens)

Attachment: py26-numpy_svn_2.2.diff added

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

comment:35 Changed 14 years ago by 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.

comment:36 in reply to:  35 Changed 13 years ago by 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>

;-)

comment:37 Changed 13 years ago by nilstec_inc@…

Cc: nilstec_inc@… added

Cc Me!

comment:38 Changed 13 years ago by jabronson@…

Cc: jabronson@… added

Cc Me!

comment:39 Changed 13 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

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.

comment:40 Changed 13 years ago by nilstec_inc@…

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

Note: See TracTickets for help on using tickets.