From simon.urbanek at r-project.org  Wed Jul 30 20:23:13 2008
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Wed, 30 Jul 2008 14:23:13 -0400
Subject: [Rd] R, Macports and C++ streams
In-Reply-To: <441C27EB-A93E-499D-BDD9-DD9645454123@ic.ac.uk>
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>
	<441C27EB-A93E-499D-BDD9-DD9645454123@ic.ac.uk>
Message-ID: <106C84A2-A236-42C0-9492-C1F395F9277C@r-project.org>


On Jul 30, 2008, at 13:16 , Ernest Turro wrote:

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

That is not exactly true - it uses whatever your gcc version is. You  
can use Apple's gcc 4.0 or 4.2, they both work.


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

FYI it's part of Xcode 3.1 ...


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

I suspect you're confusing several separate issues here - the include  
paths for OMP have nothing to do with R, they are part of the gcc and  
as such added regardless of the include flags. Just try
gcc-4.2 omp.c -o omp -fopenmp
which specifies no include flags and works just fine.

The real issue here is that Apple doesn't provide gcc-4.2 support for  
Tiger, so you cannot use 10.4 SDK unless you also install the  
corresponding libraries. Hence you have two choices:
1) install gcc-4.2 libraries in 10.4u SDK
or
2) build for Leopard-only

As for 1) you can get just the SDK files for Tiger from
http://r.research.att.com/tools/
(you'll need to symlink darwin8 directory to darwin9)
As for 2) you can use the Leopard binaries from
http://r.research.att.com/

Cheers,
Simon


>
>> 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
Simon Urbanek