[Rd] R, Macports and C++ streams
Simon Urbanek
simon.urbanek at r-project.org
Wed Jul 30 20:23:13 CEST 2008
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
>>
>>
>
>
More information about the R-devel
mailing list