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