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.

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:

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.

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.

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.

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).

"/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.

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).

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).

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.

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.

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.

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.

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:

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.