Just as a point of reference -- I use Simon's gfortran and used it to build my own Julia and R installations with no problems.
Michael On Tue, Apr 10, 2012 at 10:47 AM, Simon Urbanek <[email protected]> wrote: > > 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 <[email protected]> >> 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 >> > <[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 _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
