[R-SIG-Mac] Building R-2.4 on MacOS X

[Simon Urbanek]

Bill,

On Dec 4, 2006, at 4:42 AM, Bill Northcott wrote:

> I am helping Martyn Plummer to keep JAGS running on MacOS X.  For
> [...]
> 1.  The CRAN binary contains a library libBlasVeclib.dylib.
> Following the build method in 'The MacOS X R FAQ' this library is  
> not built.  What is the library for and would it be worth building?
>

R can be configured to use various BLAS implementations. One of  
changes in 2.4.0 is that this can be done by switching libRblas.dylib  
(e.g. via softlink). The CRAN binary comes with two BLAS  
implementations - one using vecLib (libRblas.vecLib.dylib) and the  
internal R one (libRblas.0.dylib). They have been produced in two  
separate builds. This is equivalent to configuring R with --with- 
blas='-framework vecLib' and --without-blas respectively. The  
libRblas.dylib is a symlink which can be changed depending on which  
implementation you want to use.


> 2.  I am not happy putting the R compiler directory (/usr/local/   
> gcc4.0/bin) up the front of the path because it effectively  
> replaces  the default gcc and g++.

That was the point, actually. All Apple versions of gcc up to most  
recent Xcode update had a serious bug that was producing invalid code  
- trashing the stack and leading to segfaults (on Intel Macs).


>   I have made the builds by setting F77=/usr/local/gcc4.0/bin/ 
> gfortran and letting the Apple compilers do the C and C++ code.   
> The resulting binaries pass 'make check-all' on both ppc and i386  
> with no failures.  Is there any point using the R supplied gcc and g 
> ++?
>

See above. Xcode 2.4.1 seems to have fixed that bug, so it should be  
possible to use the Apple compiler now. However, note that its ABI is  
incompatible with the FSF 4.0.3 version, so you won't be able to use  
any binary CRAN packages. For R 2.5.0 we should be (hopefully) able  
to switch back to Apple gcc, but given that Xcode 2.4.1 is not the  
default (and it's binary-incompatible), we can't do it yet.


> 3.  Building JAGS we often have problems at the linking stage with  
> many multiply defined symbols.  These are due to libtool including  
> libraries (libgcc_s and libSystem) which are already included by  
> the system.  I submitted a patch suggestion to the autoconf  
> maintainers to get rid of these problems by similar methods to that  
> used for libcrt*.  These have been accepted and are in the autoconf  
> cvs sources but not yet released.
> m4/R.m4 line 826 includes an exclusion which implements the changes  
> to exclude libcrt* which are now implemented in released versions  
> of autoconf.  The upcoming changes to exclude libgcc* and libSystem  
> can be implemented by adding '| -lgcc* | -lSystem' to the above  
> referenced line.  ( of course one needs to run 'aclocal -I m4' and  
> autoconf after the change)  My binary is built with this change and  
> it works without problem.
>

Thanks, I'll have a look.

Cheers,
Simon