[R-SIG-Mac] tools for compiling R from source on Leopard

[Michael Braun]

Simon:

Thanks, I'll try the research.att.com builds.  That's a lot easier  
than what I was trying to do.

I appreciate your help, and all of the work you do to make R happen.

Michael



On Mar 2, 2008, at 3:52 PM, Simon Urbanek wrote:

>
> On Mar 2, 2008, at 11:40 AM, Michael Braun wrote:
>
>> Simon:
>>
>> Thanks for clarifying all of this.  The statement in section 2.1.2  
>> of the MacOS FAQ is what threw me off a bit (I thought when  
>> matching 3.x and 4.x, the x had to match as well.  My mistake).   
>> Certainly, I don't need to be using experimental, unsupported  
>> tools.  Again, I probably just read way too much into the  
>> instructions.
>>
>> But I do want to be sure that I have a 64-bit build of R  that  is  
>> linked to the vecLib BLAS (similar to my current configuration on  
>> Linux).  Is there a way to do this without compiling from source?   
>> I see there are instructions on the R for MacOS developer page, but  
>> these are also flagged as "experimental."  If I don't want to be  
>> too experimental, I'm not sure how to get to where I want to go  
>> otherwise.
>>
>
> Normally you can get 64-bit build from
> http://r.research.att.com/
> but right now the x86_64 build doesn't pass make check, so it's  
> officially not available for download. The problem is a bug in the  
> gcc-4.2 compiler that miscompiles some code.
>
> Anyway, if you feel like it, you can try either
> http://r.research.att.com/R-devel-leopard-universal.tar.gz
> or
> http://r.research.att.com/R-2.6-branch-leopard-universal.tar.gz
>
> The latter is a 2.6-branch so it's a bit less experimental.
> To install, just unpack to root,e.g.
> sudo tar fxz R-devel-leopard-universal.tar.gz -C /
>
> Let me know if that works for you.
>
> As of vecLib - that's really easy - you can always symlink the  
> vecLib framework as libRblas.dylib, but all CRAN builds use vecLib  
> anyway.
>
> Cheers,
> Simon
>
>
>> On Mar 2, 2008, at 11:04 AM, Simon Urbanek wrote:
>>
>>> Michael,
>>>
>>> the instructions you are referring to (gcc-4.2-based) are for  
>>> experimental R builds using cutting-edge unreleased tools, so  
>>> you're pretty much on your own there. So let me first address  
>>> "offical" way as documented in the FAQ:
>>> The gfortran compiler the FAQ refers to is on CRAN (http://cran.r-project.org/bin/macosx/tools 
>>> ) - it is also the first download on the R for Mac Tools page.  
>>> That is all you need (Xcode + the above Fortran) and both the FAQ  
>>> and the tools page specifically say so.
>>>
>>> Now to your quest for experimental, unsupported tools (see also  
>>> comments inline below). The only reason to use gcc-4.2 is if you  
>>> want to play with OpenMP. Note that the gcc-4.2 is known to have  
>>> bugs, so tread with care.
>>>
>>>
>>>> Hi.  This week I received my very first Mac (I was previously a  
>>>> Linux  user), and I am now trying to compile R from source.  I am  
>>>> running Mac  OS 10.5.2, and I have downloaded and installed Xcode  
>>>> 3.0.  Following  instructions on the R for Mac OS FAQ page I see  
>>>> that I need to install  gfortran 4.2.1.  However, Xcode only  
>>>> comes with gcc 4.0.1, and I  understand that the versions need to  
>>>> be the same.
>>>>
>>>
>>> That is not true (and I'm not sure why concluded it). Only the  
>>> major version (3.x vs 4.x) has to match (as the FAQ tells you), so  
>>> gcc 4.0.1 + gfortran 4.2.1 are just fine.
>>>
>>>
>>>> The R for Mac tools site mentions that the Apple version for gcc  
>>>> 4.2.1 is available from ADC, but I just cannot find it anywhere
>>>
>>> ADC: http://connect.apple.com/
>>> Login, click on Downloads -> Developer Tools -> GCC 4.2 Developer  
>>> Preview 1
>>> If it's not there, please let me know.
>>>
>>>> (I Googled, searched, etc, with no luck--can someone please point  
>>>> me in the right direction?).  So, I ran  the provided  
>>>> gcc42build5531.pkg installation file.  The installer ran with no  
>>>> errors, but it doesn't seem to install anywhere
>>>
>>> Try typing
>>> gcc-4.2
>>>
>>>
>>>> (I even created a test folder to install to, but after the  
>>>> installation, that folder was empty).
>>>
>>> Which is expected - try enabling the installer log (Window- 
>>> >Installer Log) if you're interested in the details. If you're  
>>> more comfortable with command-line tools and want to learn more  
>>> about packages on OS X, have a look at "man pkgutil" and "man  
>>> installer". For old-style packages (which are bundles) see also  
>>> "man pax" and "man lsbom".
>>>
>>>
>>>> gcc --version still indicates that the version is 4.0.1.
>>>
>>> Yes, gcc is a link to gcc-4.0, not to gcc-4.2.
>>>
>>>
>>>> The gfortran-42.pkg file installed correctly.
>>>>
>>>> I know this sounds more like a Mac OS problem than an R problem,
>>>
>>> There is no problem, really ;).
>>>
>>>
>>>> but since I am using tools (and following instructions)
>>>> designed specifically for R, I thought I'd ask for help here.   I  
>>>> suppose that all I really need is to be able to effectively  
>>>> install either gcc 4.2.1 (since I have the R-approved gfortran  
>>>> 4.2.1 installed) or an R-approved gfortran 4.0.1 (since I have  
>>>> gcc 4.0.1installed).
>>>>
>>>
>>> No, that is wrong (see above). If you followed the instructions  
>>> you'd use gcc 4.0.1 from Apple and gfortran 4.2.1 from CRAN. This  
>>> is how the release is built.
>>>
>>> FWIW: Although it is a nice exercise, I'm not quite sure why you  
>>> want to build R from sources unless you want to modify it - note  
>>> that your result is likely to be incompatible with the packages we  
>>> create (unless you build the full multi-arch universal build).
>>>
>>> One more side-note on the tools: now that you have installed  
>>> several tools in your system (gcc 4.0, 4.2, two different  
>>> gfortrans etc.), you should be aware that although you can use any  
>>> combination of them, the library lookup is common to all, so  
>>> unless you de-install the gfortran from /usr/local/bin (the CRAN  
>>> verison) [via /usr/local/bin/gfortran-uninstall], even the  
>>> binaries compiled with the Leopard gfotran (/usr/bin/gfortran-4.2]  
>>> will be linked to the /usr/local/lib/libgfortran dynamic library,  
>>> because it has higher precedence than the static library that the  
>>> system gfortran supplies. This is not really a problem as long as  
>>> you are aware of it, but it that reduces the portability of your  
>>> binaries a bit (you'll have to ship the gfortran shared library  
>>> with your binaries if they use Fortran). If you don't understand  
>>> what I'm saying, don't worry too much :) it doesn't affect  
>>> anything as long as you stay on the same machine.
>>>
>>> Cheers,
>>> Simon
>>>
>>
>>
>