py25-scipy failing due to arch flags set in python25 PortGroup

[Ryan Schmidt]

On May 30, 2011, at 10:21, Adam Mercer wrote:

> In try to fix a build error in py25-scipy (#29644[1]) it's failing with:
> 
> :info:build Undefined symbols:
> :info:build   "_Py_BuildValue", referenced from:
> :info:build       _f2py_rout__fftpack_destroy_dct1_cache in _fftpackmodule.o
> :info:build       _f2py_rout__fftpack_destroy_dct2_cache in _fftpackmodule.o
> :info:build       _f2py_rout__fftpack_destroy_ddct1_cache in _fftpackmodule.o
> :info:build       _f2py_rout__fftpack_destroy_ddct2_cache in _fftpackmodule.o
> <snip>
> 
> I've found a similar report of the same error on the SciPy mailing list:
> 
> <http://mail.scipy.org/pipermail/scipy-dev/2009-November/013412.html>
> 
> and the solution was found to be that overwriting CFLAGS, LDFLAGS, and
> FFLAGS with "-arch x86_64" was leading to this error and simply not
> setting these fixed the build.
> 
> <http://mail.scipy.org/pipermail/scipy-dev/2009-December/013429.html>
> 
> These flags are set in the python25 PortGroup and commenting out the
> setting the these variables allows the build to succeed. So this is
> the same problem as was reported on the SciPy mailing list, and the
> same solution works.
> 
> I imagine these flags are set so that the build arch is respected,

The python24 and python25 portgroups were recently updated to include this capability, but this was backported from the python26 and python27 portgroups which already had it for some time. Are the py26-scipy and py27-scipy ports affected? If not, see what's different about them. It looks to me that, for example, py26-scipy contains these lines which are not in py25-scipy:

python.add_archflags    no
universal_variant       no

Those lines probably need to be added to py25-scipy and py-scipy.


> but
> they are causing a problem in this case I'm not sure of the best way
> to proceed. Is there a way I can tell the PortGroup not to set these
> flags?

-arch flags are not appropriate when using a non-Apple compiler, such as you do in the gcc variants in py*-scipy, but I thought MacPorts was supposed to know this and not append the -arch flags in that case (and use -m32/-m64 options instead as applicable).

> Doing this will mean that this port can only build the
> architecture on which it is running, do we have a syntax for
> specifying that?


I don't believe we do.