Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[mark b. <mbr...@ai...>]

On Jan 8, 2012, at 5:32 AM, Rainer Schöpf wrote:

> Hello Mark,
> 
>> "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 (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.
>> 
>> I've been discussing this with the folks at MacPorts as well. They like 
>> programs to make no attempt at all to determine what architecture of programs 
>> they can run, and would prefer programs to rely on the CFLAGS, CXXFLAGS, 
>> LDFLAGS etc. variables in which we instruct the compiler for what 
>> architecture to build. (I'm not making any requests here, only giving you 
>> background info).
>> 
>> The macports individual who tested my install script on snow leopard, had his 
>> own script to detect whether a config/make file is using ${configure.cc} 
>> instead of running "gcc" explicitly. When your config tried to determine 
>> whether the C preprocessor defines the symbol __LP64__ the aforementioned 
>> script was found instead, producing the error.
> 
> Allow me to point out again that the config.guess script that tries to determine 
> whether the C preprocessor defines the symbol __LP64__ (and from which I quoted 
> some lines in an earlier mail message) is not part of the Reduce subversion 
> repository.  It is actually generated automatically by GNU automake as part of 
> the build process.
> 
> I don't have a Mac, so I can only do an educated guess on what is causing the 
> problem.  If config.guess is indeed the cause, then this is not specific to 
> Reduce, but may appear for any other program that relies on automake/autoconf.
> 
> On the other hand, it may well be that config.guess is doing what it should, but 
> that there is an interaction with another part of the Reduce build process. 
> 

I agree. It sounds like his machine may be 64-bit that uses the 32-bit kernel. 
On my lion (10.7) machine, unam -p returned i386 but it built x86_64.

> So, this person's using his own script is a standard method, or rather not?  
> Because if it isn't "standard" in the sense that it plays well together with GNU 
> automake, I don't see what we can do (except reporting a bug against automake).
> 

It's not his own script, but one that is documented in a macports wiki:

https://trac.macports.org/wiki/UsingTheRightCompiler

The larger issue is the fact that the sdk was not found, because of this script.
For instance, in .../trunk/csl/fox/configure.ac I found these lines:

 if gcc -isysroot /Developer/SDKs/MacOSX10.7.sdk -arch ix86_64 conftest.c -o conftest > /dev/null 2>&1
 then
   AC_MSG_NOTICE([x96_64 binary creation will probably be possible using 10.7])
   else
     AC_MSG_ERROR([Need MACOSX SDK version 10.6 or 10.7])
   fi
 fi

any explicit "gcc" calls get rerouted by that script and return error. There may 
be others in your code, but I haven't looked at them all.

>> I'm now faced with a choice: either I patch the config/make scripts to make 
>> use of the environment variables (like $CC) that MacPorts passes (and I have 
>> no idea how much effort it would take), or abandon the work I started. I 
>> don't know if this is something you planned on doing already.
> 
> I don't have any problem with modifying the scripts to make them work - though I 
> think that this needs more analysis to understand the problem. Ie., is it indeed 
> config.guess that returns the wrong architecture? If so, then why does it happen 
> only for Reduce, and not for other programs that make use of GNU automake? Is 
> this a general problem, or specific to the aforementioned individual's special 
> environment?
> 
> If config.guess is right in determining the architecture, at what point is it 
> replaced by the wrong one, and why?
> 
> Did I understand correctly that you cannot test on 10.6 yourself, only on 10.7?

Right, I do not have 10.6 available to test. But I know for a fact that Xport (which
downloads the psl binaries) built on 10.6 without that script and failed with the 
script present.

Is their a quick way to search for explicit "gcc" calls in all your config/make files?

> 
>  Rainer
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers


-Mark