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 <[email protected]>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 > its 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 > > _______________________________________________ > R-SIG-Mac mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > [[alternative HTML version deleted]]
_______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
