reduce fails to build on 10.6

[Ryan Schmidt]

On Jan 5, 2012, at 22:46, Mark Brethen wrote:

> I'm having no problem building reduce on lion whereas it fails on snow leopard, which surprises me.

The version of reduce-algebra that is committed builds for me on Snow Leopard. I have not tested your newer Portfiles.

> I've reviewed the config logs from both systems and have noticed:
> 
> - The ports' config files test for "gcc" and "g++", these tests pass on lion, but don't on snow leopard. 

The compiler used should be determined by MacPorts based on the Xcode version:
Xcode 3.2.x: gcc-4.2/g++-4.2
Xcode 4.0/4.1: llvm-gcc-4.2/llvm-g++-4.2
Xcode 4.2+: clang/clang++

> - config.guess returns the correct build system type (x86_64) on lion, but i386 on snow leopard.

The architecture reported by config.guess is almost always irrelevant. Software should not be relying on it. If you are testing on two different machines, and the Lion machine is newer, then this difference could be because your Snow Leopard machine uses the 32-bit kernel while your Lion machine uses the 64-bit kernel. This is also irrelevant, unless you're building kernel extensions, which reduce doesn't.

> - it appears to force a universal build on snow-leopard (is macports doing this?)

MacPorts builds universal (for the architectures defined in universal_archs in macports.conf) if you request the +universal variant, otherwise it builds for the architecture defined in build_arch in macports.conf. It's possible reduce has special code to override these decisions; if so, we should probably remove that special code.

> - No SDK found on snow leopard, yet it exists
> 
> These lines appear in the sl main.log, but not in lion:
> 
> :info:configure gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch ppc -arch i386 -framework Carbon -framework CoreServices -framework ApplicationServices conftest.c -o conftest
> :info:configure gcc: Error: You should be using ${configure.cc}
> :info:configure See http://trac.macports.org/wiki/UsingTheRightCompiler

You have apparently followed the instructions given on the above wiki page, designed to cause this error.

> :info:configure gcc -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch ppc -arch i386 -framework Carbon -framework CoreServices -framework ApplicationServices conftest.c -o conftest
> :info:configure gcc: Error: You should be using ${configure.cc}
> :info:configure See http://trac.macports.org/wiki/UsingTheRightCompiler
> :info:configure gcc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -framework Carbon -framework CoreServices -framework ApplicationServices conftest.c -o conftest
> :info:configure gcc: Error: You should be using ${configure.cc}
> :info:configure See http://trac.macports.org/wiki/UsingTheRightCompiler
> 
> Is there any guarantee that patching all the makefiles' "gcc" calls with "$(CC)" will fix it? 

No, but that's a good place to start.

> In addition, Xport fails to build, which is needed to download the psl binaries. I know this worked on snow leopard for ryan, but this time, I'm overriding macport's config phase. Could this also be causing errors?

The modification you showed before was overriding the configure phase so that instead of letting MacPorts run the configure script, you run it yourself twice with different arguments in a system call. The difference there would be that MacPorts' configure invocation would include a bunch of environment variables, including CC, CFLAGS, CXX, CXXFLAGS, CPPFLAGS, LDFLAGS and others designed to make the port build with the right compiler and for the correct architectures and using dependencies from MacPorts. If you're going to manually all configure, you should probably pass in all these variables manually, for example:

system -W ${worksrcpath} "CC=${configure.cc} CFLAGS=\"${configure.cflags} [get_canonical_archflags cc]\" CXX=${configure.cxx} CXXFLAGS=\"${configure.cxxflags} [get_canonical_archflags cxx]\" CPPFLAGS=\"${configure.cppflags}\" LDFLAGS=\"${configure.ldflags} [get_canonical_archflags ld]\" ./configure --one --two --three"

As you see this gets a little unwieldy which is why we don't often do this kind of thing.

Can you not simply call configure a single time with both arguments? If that does not work, perhaps it would be easier to patch the configure script to make that work, than to call configure manually with all these parameters.