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