On Jan 6, 2012, at 3: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?
Or can you make two ports? Do the two build dirs require each others presence?
Regards,
Bradley Giesbrecht (pixilla)
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
