[Rd] R, Macports and C++ streams

[Ernest Turro]

On 30 Jul 2008, at 20:25, Simon Urbanek wrote:

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

Could you please clarify how you go about building packages for  
Leopard-only without using my patches?

Thanks,
Ernest

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