R, Macports and C++ streams

Wed, Jul 30, 2008 12:25 PM

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.

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

R, Macports and C++ streams

Thread (15 messages)