[Rd] R, Macports and C++ streams

[Simon Urbanek]

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

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

Yes, as I told you.


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

The easiest solution is 2) in my previous e-mail (it uses gcc-4.2 by  
default and targets Leopard) and that's what you're forcing with your  
patches anyway.

Cheers,
Simon


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