From ernest.turro at ic.ac.uk  Wed Jul 30 19:16:21 2008
From: ernest.turro at ic.ac.uk (Ernest Turro)
Date: Wed, 30 Jul 2008 18:16:21 +0100
Subject: [Rd] R, Macports and C++ streams
In-Reply-To: <036A6389-49F3-47BB-A3A4-73E05D542897@r-project.org>
References: <37E1D80F-D1CB-4B4B-80B1-DDBDB0EF43BD@ic.ac.uk>
	<25AD1EB9-4E98-4DCB-8C36-43B1247121ED@r-project.org>
	<33D233DE-7D1D-47E1-BC9C-5659A9C4D215@ic.ac.uk>
	<036A6389-49F3-47BB-A3A4-73E05D542897@r-project.org>
Message-ID: <441C27EB-A93E-499D-BDD9-DD9645454123@ic.ac.uk>


On 30 Jul 2008, at 18:04, Simon Urbanek wrote:

>
> On Jul 30, 2008, at 12:32 , Ernest Turro wrote:
>
>>
>> On 30 Jul 2008, at 15:46, Simon Urbanek wrote:
>>
>>>
>>> On Jul 30, 2008, at 9:45 , Ernest Turro wrote:
>>>
>>>> Dear all,
>>>>
>>>> R on Macports relies on GCC 4.3 to build packages. I find that  
>>>> packages with shared objects that use C++ streams crash R if  
>>>> they're compiled using Macports' gcc43, but work fine if compiled  
>>>> in exactly the same way using Apple-supplied GCC 4.2. Has anyone  
>>>> here had the same issue/know what is causing this problem?
>>>>
>>>
>>> Using compilers from MacPorts and similar suites (Darwin ports,  
>>> Fink etc.) is strongly discouraged (and outright not supported by  
>>> the CRAN binary) since they have been known to be badly broken in  
>>> the past and when whenever tested so far they were incomplete and  
>>> incompatible. You have to re-compile R yourself with those tools  
>>> (and you're entirely on your own) if you really want to use them.  
>>> CRAN binaries work only with Apple's gcc branches, if you want to  
>>> use anything else, you have to follow the unix R instructions and  
>>> compile everything from sources.
>>
>> Dear Kjell,
>>
>> As you can see above, your R port on Macports appears to be broken  
>> and has a reputation of having been broken for a while. I for one  
>> have experienced odd problems as described above. To avoid further  
>> issues with unsuspecting Macports users, perhaps it would be good  
>> to pull the port from the repository until a decent level of  
>> reliability can be provided ?
>>
>
> Although I do agree on your last point, I just want to clarify that  
> I was talking about supported R for Mac setup (as provided in binary  
> form on CRAN).

Having installed the R binary for Mac, I've noticed that it uses  
Apple's default gcc 4.0.1. The problem with this is that there is no  
OpenMP support in gcc until version 4.2, which is available as a  
preview from apple on ADC. Changing gcc and g++ to gcc-4.2 and g++-4.2  
in the default Makeconf isn't quite enough, as R also needs to look in  
the appropriate header paths, etc...(e.g. to find omp.h). Could you  
recommend an easy way of getting a binary R installation to work with  
apple-supplied gcc 4.2 instead of 4.0 ?

Thanks,

Ernest



> Although it should be possible to build R with non-Apple gcc, but it  
> must be done very carefully, because there are many dangers lurking  
> in the interaction of system libraries with those from non-Apple  
> tools. This has nothing to do with R, it's about knowledge how  
> things work in OS X and it is very important when compilers are  
> involved [unfortunately there are many binaries around from people  
> that don't understand the intricacies of OS X well enough and think  
> it's almost like a Linux box - I'm not talking about MacPorts in  
> particular, it's just a general observation].
>
> Cheers,
> Simon
>
>



[Rd] R, Macports and C++ streams
Ernest Turro