reduce fails to build on 10.6

[Mark Brethen]

On Jan 6, 2012, at 5:11 PM, Ryan Schmidt wrote:

> 
> 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.
> 
> 

Some of the discussion here and on ticket #32759 is due to the fact that I do not have a clear understanding of how MacPorts works and do not have any c-compiler experience (I write ansys apdl scripts occasionally, and dabble with bash scripting). 

I do not have Snow Leopard, so Jeremy had volunteered to test the port on his machine, after which he reported that the port should be using the right compiler. It took me a while to figure out what he was talking about (after reading through the wiki twice) and the fact that the script he implemented was a problem. Since uname -p returns i386 on 64 bit Darwin, reduce's config tries to determine whether the C preprocessor defines the symbol _LP64_, and the aforementioned script is found instead of the actual program. 

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.

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)?


Mark