[R-SIG-Mac] Compiling 2.6.0 on OS 10.3.9: success [was: Compiling 2.5.1 on OSX Panther (James Kyle)]

[Simon Urbanek]

Jari,

On Nov 7, 2007, at 4:50 AM, Jari Oksanen wrote:

> I have now succeeded in compiling R 2.6.0 on MacOS 10.3.9. The history
> of the problems was:
>
> 1. ./configure test introduced in R 2.4.0 regarded MacOS 10.3.9  
> vecLib as incomplete BLAS, and ignored arguments --with-blas='- 
> framework vecLib' --with-lapack, and decided to build dlapack  
> irrespective of configure arguments.
>

Can you send me the config.log, please? Something must have failed so  
that vecLib is unusable for lapack in that setup.


> 2. Building dlapack failed.
>
> It seems that building dlapack failed only if configure specified -- 
> disable-R-framework. With --enable-R-framework (default) the  
> building ended normally, and the resulting binary passed make check.
>
> The reason why I used --disable-R-framework was that I was trying to  
> build a command line version of R for /usr/local/bin and  
> simultaneously keep the old R-2.3.0 that works with the R GUI (R.app).


You can have as many versions of R in the framework as you wish, the  
framework install will still keep the old R intact. Also the framework  
is built only at install time, so the compiled R is equivalent to non- 
framework R and you can move it anywhere you like (including /usr/ 
local). That's why I'm wondering why the lapack result is different -  
both builds should be technically identical, the only difference is  
the way the binaries are installed.


> Switches --disable-R-framework --prefix=/usr/local/bin looked like a  
> sensible choice for me. With enabled framework I also can use the  
> command line, but now I need a symbolic link deep from the heart of  
> the framework (in non-default location) to /usr/local/bin/R.
>

Well, I don't see the difference here - with installed R you need a  
symlink (or a copy which is the default) from a non-standard location  
as well ... :P The only difference is that it is done by make install  
(however, for the framework by the CRAN installer).


> The reason why I wanted to have only a command line version was that  
> R.app (R GUI) was documented to need MacOS 10.4.4 and building of  
> R.app is reported to need version of XCode that is not available for  
> MacOS 10.3.9 (latest available XCode version is 1.5, R.app claims to  
> require XCode 2.4.0  --r.research.att comm page claims that R  
> requires that toolset, but seemingly it doesn't expect for the GUI).
>

Xcode 2.4.0+ is required only for universal builds on Tiger and  
higher. On Panther you can use whatever Xcode works there, but given  
that we cannot test it, it's not officially supported. Also see the  
FAQ - R.app has an alternative project for old Xcode versions and also  
a way to build the unix-way with a makefile. I addition, the CRAN  
R.app binaries actually used to work on Panther just fine, because  
they don't use any Tiger-specific features. However, I don't a have a  
Panther anymore, so I cannot test either the build or the binaries, so  
I don't know if all that is still true.

Cheers,
Simon


> I did some other things under way that may have contributed to the
> success, like upgraded my XCode toolset to 1.5 (although I had to
> register and approve US sanctions against some countries). I also  
> tried
> this with and without fink, but the build succeeded in both cases
> (except that html help pages could be built only with fink, since the
> makeinfo is < 4.7 in MacOS 10.3.9).
>
> Best wishes, Jari Oksanen
> -- 
> Jari Oksanen <jari.oksanen at oulu.fi>
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
>