Skip to content

R, Macports and C++ streams

15 messages · Ernest Turro, Kjell Konis, Simon Urbanek

Original
Ernest Turro
# 
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?

Thanks,

Ernest
Kjell Konis
# 
I found this in Writing R Extensions:

"Using C++ iostreams, as in this example, is best avoided. There is no  
guarantee that the output will appear in the R console, and indeed it  
will not on the R for Windows console. Use R code or the C entry  
points (see Printing) for all I/O if at all possible."

That is, use Rprintf() instead. The fact that your code works with one  
version of gcc and not another can probably be chalked up to  
coincidence.

Kjell
On Jul 30, 2008, at 3:45 PM, Ernest Turro wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Jul 30, 2008, at 9:45 , Ernest Turro wrote:

        

            

      
      
      
    

        
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.

Cheers,
Simon

  
  


  


      

    

    

      
      

        


  

        

      Ernest Turro
    

    

      
      #
    

  


  

      
On 30 Jul 2008, at 15:46, Simon Urbanek wrote:

        

            

      
      
      
    

        
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 ?

Cheers,

Ernest

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ernest Turro
    

    

      
      #
    

  


  

      
On 30 Jul 2008, at 15:18, Kjell Konis wrote:

        

            

      
      
      
    

        
The doc warns that the output to stdout using iostreams may not appear  
on the console, there is no indication that doing this may crash R  
(and this has never happened to me before). Certainly, the use of file  
streams (fstreams) should work just fine.

Ernest

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Jul 30, 2008, at 12:35 , Ernest Turro wrote:

        

            

      
      
      
    

        
FWIW I saw this problem when using mismatching compilers before (long  
time ago when we had to use FSF-built gcc because of bugs in Apple's  
gcc). Its likely cause is a combination of incompatible ABIs and  
libstdc++ mismatch. Note that Apple's gcc build script goes into great  
pains to not mess up system stdc++ because it's asking for trouble.

Cheers,
Simon

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Jul 30, 2008, at 12:32 , Ernest Turro wrote:

        

            

      
      
      
    

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

  
  


  


      

    

    

      
      

        


  

        

      Ernest Turro
    

    

      
      #
    

  


  

      
On 30 Jul 2008, at 17:58, Simon Urbanek wrote:

        

            

      
      
      
    

        
Yes, this sounds like the most likely culprit. I guess, ultimately,  
Macports GCC maintainers should make sure their build script goes  
through the same hoops as Apple's to avoid this kind of mismatch  
problem with libstdc++. The best thing would be for the R port to  
depend on Apple-supplied gcc rather than the Macports gcc.

Cheers
Ernest

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ernest Turro
    

    

      
      #
    

  


  

      
On 30 Jul 2008, at 18:04, Simon Urbanek wrote:

        

            

      
      
      
    

        
Having installed the R binary for Mac, I've noticed that it uses  
Apple's default gcc 4.0.1. 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. 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 ?

Thanks,

Ernest

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

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

        

            

      
      
      
    

        
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.

            

      
      
      
    

        
FYI it's part of Xcode 3.1 ...

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ernest Turro
    

    

      
      #
    

  


  

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

        

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

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

        

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ernest Turro
    

    

      
      #
    

  


  

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

        

            

      
      
      
    

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

Thanks,
Ernest

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Kjell Konis
    

    

      
      #
    

  


  

      
Ernest,

Is it possible to provide a reproducible example of your crash?

Kjell

        
On Jul 30, 2008, at 6:32 PM, Ernest Turro wrote:

        

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ernest Turro
    

    

      
      #
    

  


  

      
On 31 Jul 2008, at 10:29, Kjell Konis wrote:

        

            

      
      
      
    

        
Yes. R on macports depends on gcc43, which is causing the problems.  
The best thing would be to make the port not depend on gcc43, and  
instead depend on apple-supplied gcc (if this is possible).  
Alternatively, the macports gcc43 build script should be fixed (e.g.  
by looking at Apple's script, if available). Reproducible example:

Download and install gcc43 from Macports

cat - > foo.txt
Blah
Blah
^D

cat - > foo.cc
#include <stdio.h>
#include <fstream>
extern "C" {
   void foo() {
     char bar;
     std::ifstream ifs("foo.txt");
     std::ofstream ofs("foo2.txt");
     ifs >> bar;
     ofs << bar;
   }
}
^D

cat - > foo.R
dyn.load("foo.so")
.C("foo")
^D

# Crash:
g++-mp-4.3 -shared -fPIC foo.cc -o foo.so
R --vanilla < foo.R

# Don't crash:
g++-4.2 -shared -fPIC foo.cc -o foo.so
R --vanilla < foo.R