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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
