On Jan 6, 2012, at 19:48, Mark Brethen wrote: > Since uname -p returns i386 on 64 bit Darwin
"uname -p" returns the architecture of the kernel. On an Intel Mac that could be i386 or x86_64, depending on what kernel your Mac uses. There are 32-bit Macs (like the original MacBookPro1,1) that use the 32-bit kernel, there are 64-bit Macs (like my MacBookPro3,1) that use the 32-bit kernel, and there are more modern 64-bit Macs that use the 64-bit kernel. The bitness of the kernel is not an indication of the architecture of programs the computer can run, and programs should not use the output of "uname -p" to decide what architecture of programs they can run. In MacPorts, we would like programs to make no attempt at all to determine what architecture of programs they can run. We would like programs to rely on the CFLAGS, CXXFLAGS, LDFLAGS etc. variables in which we instruct the compiler for what architecture to build. > You say that MacPorts' configure invocation would include a bunch of > environment variables, etc. but I can't see how that helps, since the > configure script, and I assume the make files as well, are running "gcc" > explicitly. Correct; in that case, you would first have to patch the configure script to make use of the environment variables (like $CC) that MacPorts passes. > According to the build file, you should call config with one or the other. I > think this is because each one has mutually exclusive sets of additional > arguments. But I have not tried calling both. > > So, what's the most efficient way to patch the configure/make files (csl has > quite a few)? I don't know; I haven't read it. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
