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
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
