py26-numpy +gcc44 requires gcc45 variant of atlas

[Michael Dickens]

On Sep 14, 2010, at 2:41 PM, Jeff Singleton wrote:
> How could "I" be compiling for one arch and then linking another ... I'm using MacPorts.  I would assume that if a Port has support for universal, then MP would adhere to this and build universal.

As pointed out by Ryan, many MP developers / maintainers do not test for +universal (or, for that matter, other variants).  I'm certainly guilty of not doing it in the past, but I'm testing for it now & will continue to do so in the future as I add / fix ports.  All of that said, MacPorts is not infallible as an install system -- we as developers / maintainers do the best we can, I think, but there's always room for doing it better somewhere.  I would guess that none of us work exclusively on MP, instead giving it time & attention as our work load allows -- so, don't expect miracles.  MP works well overall, and we continue to work to improve both port as well as the portfiles.

> If the compiling from .c to .o is done as 32-bit, but trying to link 64-bit, then I would say that the maintainer of said port needs to look at this and fix it.

Many of these types of issues should really be fixed upstream (at the developer of the project), not by us maintainers of the ports.  Let me elaborate via my current issue:

In this case, the issue is in how numpy's setup.py does its internal "configure" checking -- verifying that the compiler works & finding headers and such --, not directly in how MacPorts is interfacing with it.  From what I can tell -- and, I really haven't figured out where in the setup.py scripts all these testing takes place -- numpy does the following test (among others; this is the first one that involves linking AFAICT):

1) create conftest.c
2) ${CC} -c ${CFLAGS} -o conftest.o conftest.c
3) Change CFLAGS -> CFLAGS2: if the compiler is Apple's GCC, then it copies any -arch flag, but if it's not Apple's GCC then it clears out the CFLAGS2.
4) ${CC} ${CFLAGS2} -o conftest conftest.o

So, when port tries to build numpy as 32-bit by setting "CFLAGS=-m32" (because port is not using Apple's GCC for this purpose, and thus this flag is the only way to compile as 32-bit), step (2) creates a 32-bit .o file but step (3) clears out CFLAGS2 & thus step (4) fails because the default link arch is x86_64 & none of the provided .o files are of that architecture.  This is not the port maintainer's fault; it's the upstreams'.

So, there are 2 issues here:

A) GCC (Apple's of not) should be "smart enough" to check through all of the provided .o files and libraries to auto-determine the arch setting if just one is possible; and, erroring out if not.  Doing so is -way- beyond the expectation of your typical port maintainer.

B) Numpy's setup.py scripts should check for arch flags in C*FLAGS and carry them over for this and other linking tests.  Again, doing so is also -way- beyond the expectation of your typical port maintainer.

Arch flags vary greatly between OS/Compiler types.  setup.py handles -a lot- of different types, much as GNU's autotools, QMake, and CMake do; there is no perfect, generic way to do this "configure" oriented testing. - MLD