[R-SIG-Mac] gfortran question

[Anand C. Patel]

Ah.  OK.  Disabled.  Got it.

Will the 2.7 leopard universal nightlies also (please, please, please) be
compiled for x86_64?

Despite multiple protestations from very smart people who I hold in great
esteem, I am exceeding the per-process memory limits in 32-bit OS X during
routine analyses (ok, routine analyses with a great number of arrays), and the
x86_64 build fixes that.

Thanks,
Anand

------ Original Message ------
Received: Fri, 09 Nov 2007 10:25:40 AM MST
From: Simon Urbanek <simon.urbanek at r-project.org>
To: Anand C. Patel <acpatel at usa.net>Cc: "Todd A. Johnson"
<tjohnson at src.riken.jp>, R List <r-sig-mac at stat.math.ethz.ch>
Subject: Re: [R-SIG-Mac] gfortran question

> Anand,
> 
> On Nov 9, 2007, at 12:04 PM, Anand C. Patel wrote:
> 
> > Does this mean that the Quartz/Aqua support has been backported into  
> > 2.6?
> >
> 
> No, it's simply disabled. Technically speaking the 64-bit Quartz is a  
> big and new change (it's a complete re-write of the Quartz device,  
> hence aka Quartz II), so for QC reasons it cannot go to R 2.6.x. Also  
> it's untested with the old GUI (there is a new Leopard GUI in the  
> works that uses a different approach), so I don't feel comfortable  
> putting it in the release. However, it's trivial to back-port if you  
> desire so since the code didn't change, but then you may as well just  
> pick R-devel.
> 
> 
> > I have a working copy of R 2.6 compiled for both i386 and x86_64 (as  
> > advised) that is working nicely with bioconductor packages.
> >
> > The 64-bit version does allow me to run the large maSigPro analysis  
> > without malloc errors, which is great!
> >
> >
> >> No. R-devel compiles just fine and it did so for quite a while.  
> >> (FWIW:
> >> R-2.6-branch compiles now, too.)
> >>
> >>
> >>> 2)  working configure commmands (in other words, should I still just
> >>> be
> >>> typing in what's listed for building 64-bit R on Simon's web-site?
> >>> with
> >>> changing "8.8.1" to "9.0.0")
> >>>
> >>
> >> The configure "command" supplied with R works just fine.
> >
> >
> > Does this mean we can use just ../R-patched/configure?  I would  
> > assume we'd
> > still need to generate both i386 and x86_64 versions using  
> > subdirectories and
> > specific configure calls i.e.:
> > ../R-patched/configure CC='gcc -arch x86_64' CXX='g++ -arch x86_64' \
> > F77='gfortran -arch x86_64' FC='gfortran -arch x86_64' 'CFLAGS=-g -O3
> > -I/readline/include -L/readline/lib' 'OBJCFLAGS=-g -O3 -I/readline/ 
> > include
> > -L/readline/lib' 'LDFLAGS=-L/usr/local/lib' 'FFLAGS=-g -O3
> > -I/readline/include -L/readline/lib ' 'CXXFLAGS=-g -O3 -I/readline/ 
> > include
> > -L/readline/lib' 'FCFLAGS=-g -O3 -I/readline/include -L/readline/ 
> > lib' \
> > r_arch=x86_64 \
> > --with-blas='-framework vecLib' --with-lapack  \
> > --with-system-zlib --build=x86_64-apple-darwin9.0.0 \
> > --with-tcl-config=/usr/local/lib/tclConfig.sh
> > --with-tk-config=/usr/local/lib/tkConfig.sh \
> > --without-aqua
> >
> > Is this not the case?
> >
> 
> It is, but you're using the same configure script ;).
> 
> My current Leopard flags are as simple as setting r_arch and adding - 
> arch x86_64 to the compilers. BTW: there will be at least an  
> unofficial Leopard nightly build soon (I'm just shuffling my machines  
> to have one for the Tiger builds and one for the Leopard builds).
> 
> Cheers,
> Simon
> 
> 
>