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

[Rainer S. <rai...@gm...>]

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. 

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

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

  Rainer