GCC on Lion and above

Hi All,

HPC seem to be maintaining the gcc toolchain up to date (they have GCC 4.7 compiled with autovectoring using OpenMP?)

http://hpc.sourceforge.net

BUT the page  http://r.research.att.com/tools/  says "do not use compilers from HPC, they won't work correctly!? Is that the case?

Also, I wondered if http://www.macports.org might be the way to go to get a version of gcc with a non-crashing OpenMP library?

PS: The att.com page talks about install disks for OS X, but I think it?s all via the app store now, including X Code.

Hi All,

HPC seem to be maintaining the gcc toolchain up to date (they have GCC 4.7 
compiled with autovectoring using OpenMP?)

http://hpc.sourceforge.net

BUT the page  http://r.research.att.com/tools/  says "do not use 
compilers from HPC, they won't work correctly!? Is that the case?

Also, I wondered if http://www.macports.org might be the way to go to get 
a version of gcc with a non-crashing OpenMP library?

best wishes and thanks for your help

tim

PS: The att.com page talks about install disks for OS X, but I think it?s 
all via the app store now, including X Code.

On Monday, April 2, 2012 8:30:46 AM UTC-7, Timothy Bates wrote:
Hi All,
HPC seem to be maintaining the gcc toolchain up to date (they have GCC 4.7 compiled with autovectoring using OpenMP?)

http://hpc.sourceforge.net

BUT the page  http://r.research.att.com/tools/  says "do not use compilers from HPC, they won't work correctly!? Is that the case?

Also, I wondered if http://www.macports.org might be the way to go to get a version of gcc with a non-crashing OpenMP library?

best wishes and thanks for your help

tim

PS: The att.com page talks about install disks for OS X, but I think it?s all via the app store now, including X Code.


As far as I am aware, the problem with HPC binaries or MacPorts builds is that they cannot compile universal binaries. In order to do this, you need to build GFortran from Apple's patched sources for GCC 4.2.x or use Simon's binaries from r.research.att.com.

If you don't care about a multi-architecture version of R, then the HPC and MacPorts builds will probably work just fine---you may need to set R_ARCHS or build a single-architecture version yourself so that R does not try to build universal binaries when compiling packages from source.

Dear Simon,

I want to try the julia language on MAC as Prof. Douglas Bates mentioned these days. I only installed your gfortran-4.2.3.dmg but did not install the gnu fortran from http://hpc.sourceforge.net or http://gcc.gnu.org/wiki/GFortranBinaries as julia language requires. When I try to run julia, I get the error message:

dlopen(/Users/huang/julia/lib/libamos.dylib, 2): Library not loaded: /usr/local/lib/libgfortran.3.dylib
  Referenced from: /Users/huang/julia/lib/libamos.dylib
  Reason: image not found

I checked my /usr/bin/local and there is only libgfortran.2.dylib (no libgfortran.3.dylib) there. Is this because the gfortran-4.2.3 a little old?

If I further install newer version of GNU Fortran, will the gfortran-4.2.3 still be kept? Will this affect my compilation of R? Thanks.

Huang

On Tue, Apr 3, 2012 at 2:06 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
Tim,

On Apr 2, 2012, at 11:30 AM, Timothy Bates wrote:

Hi All,

HPC seem to be maintaining the gcc toolchain up to date (they have GCC 4.7 compiled with autovectoring using OpenMP?)

http://hpc.sourceforge.net

BUT the page  http://r.research.att.com/tools/  says "do not use compilers from HPC, they won't work correctly!? Is that the case?

Two reasons: a) they do not use Apple's drivers, so those are incompatible with most "regular" flags on Mac OS X (including most basic ones like -arch). b) last time I checked they were broken, i.e. the distribution did not even include libraries that the compiler linked against and it had OS version issues (i.e. it worked only on a very specific version which was not even what they were advertized for). I would hope that the latter point may have been rectified in the meantime, but I don't know. Gaurav never responded to my comments so I stopped worrying about that build. (There was a point c) where his compilers don't support ppc cross-compilation but that is less relevant now).

It is stil possible to build FSF gcc and Apple drivers - that's what we used a while ago when Apple's branch was broken.

But note that even the most recent compilers are not much better, OMP performance is unusable for R's purpose so last time I checked there were no noticeable gains after all the work, but more recent reports are welcome.

Also, I wondered if http://www.macports.org might be the way to go to get a version of gcc with a non-crashing OpenMP library?

MacPorts are quite notorious for the quality of the binaries and conflicts they cause, so I would be wary about that. If you compile everything from scratch (R and libraries), then the HPC compilers may work - you just have to stick to FSF flags.

I am still weighting the options - the most reasonable way at the moment is clang because it is supported by Apple and under active development (personally, I have switched to clang because it's much better for development), but there is no OpenMP yet for clang, although it is (allegedly) brewing. But as I said, at least for R itself, the threading performance problem is deeper, so just updating the compiler or OMP doesn't seem to help (I didn't try MPC, though).

PS: The att.com page talks about install disks for OS X, but I think it?s all via the app store now, including X Code.

Yes, it varies by Xcode version and your OS X version. App store is the last resort, I prefer ADC which has always worked and still works. I think the FAQ is up to date.

Cheers,
Simon

Dear Simon,

My question is whether I can install gfortran-4.2.3 and the newer GNU version at the same time such that I can compile R.

I am not expecting any julia help from you. Thanks.

Huang

On Tue, Apr 10, 2012 at 9:47 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
Huang,

you're on the wrong mailing list, I'm not a julia developer nor do I endorse or support julia - please ask their mailing lists for support.

Cheers,
Simon


On Apr 10, 2012, at 6:07 AM, huang min wrote:

Dear Simon,

I want to try the julia language on MAC as Prof. Douglas Bates mentioned these days. I only installed your gfortran-4.2.3.dmg but did not install the gnu fortran from http://hpc.sourceforge.net or http://gcc.gnu.org/wiki/GFortranBinaries as julia language requires. When I try to run julia, I get the error message:

dlopen(/Users/huang/julia/lib/libamos.dylib, 2): Library not loaded: /usr/local/lib/libgfortran.3.dylib
  Referenced from: /Users/huang/julia/lib/libamos.dylib
  Reason: image not found

I checked my /usr/bin/local and there is only libgfortran.2.dylib (no libgfortran.3.dylib) there. Is this because the gfortran-4.2.3 a little old?

If I further install newer version of GNU Fortran, will the gfortran-4.2.3 still be kept? Will this affect my compilation of R? Thanks.

Huang

On Tue, Apr 3, 2012 at 2:06 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
Tim,

On Apr 2, 2012, at 11:30 AM, Timothy Bates wrote:

Hi All,

HPC seem to be maintaining the gcc toolchain up to date (they have GCC 4.7 compiled with autovectoring using OpenMP?)

http://hpc.sourceforge.net

BUT the page  http://r.research.att.com/tools/  says "do not use compilers from HPC, they won't work correctly!? Is that the case?

Two reasons: a) they do not use Apple's drivers, so those are incompatible with most "regular" flags on Mac OS X (including most basic ones like -arch). b) last time I checked they were broken, i.e. the distribution did not even include libraries that the compiler linked against and it had OS version issues (i.e. it worked only on a very specific version which was not even what they were advertized for). I would hope that the latter point may have been rectified in the meantime, but I don't know. Gaurav never responded to my comments so I stopped worrying about that build. (There was a point c) where his compilers don't support ppc cross-compilation but that is less relevant now).

It is stil possible to build FSF gcc and Apple drivers - that's what we used a while ago when Apple's branch was broken.

But note that even the most recent compilers are not much better, OMP performance is unusable for R's purpose so last time I checked there were no noticeable gains after all the work, but more recent reports are welcome.

Also, I wondered if http://www.macports.org might be the way to go to get a version of gcc with a non-crashing OpenMP library?

MacPorts are quite notorious for the quality of the binaries and conflicts they cause, so I would be wary about that. If you compile everything from scratch (R and libraries), then the HPC compilers may work - you just have to stick to FSF flags.

I am still weighting the options - the most reasonable way at the moment is clang because it is supported by Apple and under active development (personally, I have switched to clang because it's much better for development), but there is no OpenMP yet for clang, although it is (allegedly) brewing. But as I said, at least for R itself, the threading performance problem is deeper, so just updating the compiler or OMP doesn't seem to help (I didn't try MPC, though).

PS: The att.com page talks about install disks for OS X, but I think it?s all via the app store now, including X Code.

Yes, it varies by Xcode version and your OS X version. App store is the last resort, I prefer ADC which has always worked and still works. I think the FAQ is up to date.

Cheers,
Simon

On Apr 10, 2012, at 10:26 AM, huang min wrote:

Dear Simon,

My question is whether I can install gfortran-4.2.3 and the newer GNU version at the same time such that I can compile R.

Note that your issue is really with julia's missing runtime, that's not really about the compilers per se.

So if your question is "can I have two different gfortran compilers installed" then the answer is yes, if you know what you're doing - you have to make sure they don't pick each other's runtimes at compile time.

I am not expecting any julia help from you. Thanks.

But it is a julia issue, because AFAICS you're using binaries of julia that are incomplete. Just adding the missing libraries should solve that problem (regardless of compilers).

If you compile everything from source, you can use pretty much any compiler (with the appropriate flags) and there will be no run-time issues, but then you can't use binaries.

Cheers,
Simon

Huang

On Tue, Apr 10, 2012 at 9:47 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
Huang,

you're on the wrong mailing list, I'm not a julia developer nor do I endorse or support julia - please ask their mailing lists for support.

Cheers,
Simon


On Apr 10, 2012, at 6:07 AM, huang min wrote:

Dear Simon,

I want to try the julia language on MAC as Prof. Douglas Bates mentioned these days. I only installed your gfortran-4.2.3.dmg but did not install the gnu fortran from http://hpc.sourceforge.net or http://gcc.gnu.org/wiki/GFortranBinaries as julia language requires. When I try to run julia, I get the error message:

dlopen(/Users/huang/julia/lib/libamos.dylib, 2): Library not loaded: /usr/local/lib/libgfortran.3.dylib
? Referenced from: /Users/huang/julia/lib/libamos.dylib
? Reason: image not found

I checked my /usr/bin/local and there is only libgfortran.2.dylib (no libgfortran.3.dylib) there. Is this because the gfortran-4.2.3 a little old?

If I further install newer version of GNU Fortran, will the gfortran-4.2.3 still be kept? Will this affect my compilation of R? Thanks.

Huang

On Tue, Apr 3, 2012 at 2:06 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
Tim,

On Apr 2, 2012, at 11:30 AM, Timothy Bates wrote:

Hi All,

HPC seem to be maintaining the gcc toolchain up to date (they have GCC 4.7 compiled with autovectoring using OpenMP?)

http://hpc.sourceforge.net

BUT the page ?http://r.research.att.com/tools/ ?says "do not use compilers from HPC, they won't work correctly!? Is that the case?

Two reasons: a) they do not use Apple's drivers, so those are incompatible with most "regular" flags on Mac OS X (including most basic ones like -arch). b) last time I checked they were broken, i.e. the distribution did not even include libraries that the compiler linked against and it had OS version issues (i.e. it worked only on a very specific version which was not even what they were advertized for). I would hope that the latter point may have been rectified in the meantime, but I don't know. Gaurav never responded to my comments so I stopped worrying about that build. (There was a point c) where his compilers don't support ppc cross-compilation but that is less relevant now).

It is stil possible to build FSF gcc and Apple drivers - that's what we used a while ago when Apple's branch was broken.

But note that even the most recent compilers are not much better, OMP performance is unusable for R's purpose so last time I checked there were no noticeable gains after all the work, but more recent reports are welcome.

Also, I wondered if http://www.macports.org might be the way to go to get a version of gcc with a non-crashing OpenMP library?

MacPorts are quite notorious for the quality of the binaries and conflicts they cause, so I would be wary about that. If you compile everything from scratch (R and libraries), then the HPC compilers may work - you just have to stick to FSF flags.

I am still weighting the options - the most reasonable way at the moment is clang because it is supported by Apple and under active development (personally, I have switched to clang because it's much better for development), but there is no OpenMP yet for clang, although it is (allegedly) brewing. But as I said, at least for R itself, the threading performance problem is deeper, so just updating the compiler or OMP doesn't seem to help (I didn't try MPC, though).

PS: The att.com page talks about install disks for OS X, but I think it?s all via the app store now, including X Code.

Yes, it varies by Xcode version and your OS X version. App store is the last resort, I prefer ADC which has always worked and still works. I think the FAQ is up to date.

Cheers,
Simon