From ernest.turro at ic.ac.uk  Wed Jul 30 21:13:02 2008
From: ernest.turro at ic.ac.uk (Ernest Turro)
Date: Wed, 30 Jul 2008 20:13:02 +0100
Subject: [Rd] R, Macports and C++ streams
In-Reply-To: <106C84A2-A236-42C0-9492-C1F395F9277C@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>
	<441C27EB-A93E-499D-BDD9-DD9645454123@ic.ac.uk>
	<106C84A2-A236-42C0-9492-C1F395F9277C@r-project.org>
Message-ID: <EE3F5C67-0D75-4020-9C8F-B57384F45E34@ic.ac.uk>


On 30 Jul 2008, at 19:23, Simon Urbanek wrote:

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


Thanks. I just realised that what was causing compilation to fail was  
the inclusion of the "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" flag.

So now I have a package that compiles fine I think on most systems (I  
use the AC_OPENMP macro to check for openmp support, which it will  
generally not find on a Mac).

Leopard users wishing to use openmp must:

1) install apple-supplied gcc 4.2 (e.g. via Xcode 3.1)
2) replace gcc and g++ by gcc-4.2 and g++4.2 respectively in Makeconf  
(or create appropriate symlinks)
3) remove all instances of "-isysroot /Developer/SDKs/MacOSX10.4u.sdk"  
in Makeconf

I have found this to work on my system. But is this the easiest  
solution for Mac users wishing to use openmp in the package - or can  
you think of a way of avoiding 3) ?

Thanks for your help,

Ernest


>
>
> 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
Ernest Turro