Skip to content

64-bit R compiling problem on Leopard

10 messages · Tae-Hoon Chung, Simon Urbanek, Brian Ripley +1 more

Original
Simon Urbanek
#
On Dec 6, 2007, at 9:40 PM, ? ?? wrote:

            

      
      
      
    

        
I'm pretty sure that your /usr/bin/R comes from a different build.  
Make sure you remove old scripts.

FWIW: dual 32-bit and 64-bit binaries of current R 2.6.1 patched and R- 
devel for Leopard are available from
http://r.research.att.com/
They support all four architectures. To start 64-bit Intel R use R -- 
arch=x86_64, for 64-bit ppc it is R --arch=ppc64.

Cheers,
Simon

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Tae-Hoon Chung
    

    

      
      #
    

  


  

      
The binaries in http://r.research.att.com/ worked great!
Thanks a lot for the tip.

However, when I tried to install bioconductor libraries using  
biocLite, I got the following error message:

bash-3.2$ R --arch=x86_64

R version 2.6.1 Patched (2007-12-06 r43615)
Copyright (C) 2007 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

 > source("http://www.bioconductor.org/biocLite.R")
 > biocLite(lib="~/Library/R64")
Running biocinstall version 2.1.8 with R version 2.6.1
Your version of R requires version 2.1 of Bioconductor.
Will install the following packages:
  [1] "affy"         "affydata"     "affyPLM"      "annaffy"       
"annotate"
  [6] "Biobase"      "Biostrings"   "DynDoc"       "gcrma"         
"genefilter"
[11] "geneplotter"  "hgu95av2"     "limma"        "marray"        
"matchprobes"
[16] "multtest"     "ROC"          "vsn"          "xtable"        
"affyQCReport"
Please wait...

trying URL 'http://bioconductor.org/packages/2.1/bioc/bin/macosx/universal/contrib/2.6/affy_1.16.0.tgz'
Content type 'application/x-gzip' length 1683130 bytes (1.6 Mb)
opened URL
==================================================
downloaded 1.6 Mb

... < skip > ...

trying URL 'http://bioconductor.org/packages/2.1/bioc/bin/macosx/universal/contrib/2.6/affyQCReport_1.16.0.tgz'
Content type 'application/x-gzip' length 145478 bytes (142 Kb)
opened URL
==================================================
downloaded 142 Kb


The downloaded packages are in
         /var/folders/T0/T0X1+9S9ExGTArjMjd98hk+++TI/-Tmp-//Rtmp90AT9K/ 
downloaded_packages
 > library(affy, lib="~/Library/R64")
Error: package 'affy' is not installed for 'arch=x86_64'

Is there any special way to install any packages for 64-bit compatible  
manner?

Thanks in advance,

2007. 12. 08, ?? 2:11, Simon Urbanek ??:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        
Tae-Hoon Chung

Korea Centers for Disease Control & Prevention (KCDC)
Korea National Institute of Health (KNIH)
Center for Genome Sciences, Biobank for Health Sciences

194 Tongil-ro, Eunpyoung-gu, Seoul, 122-701, Korea

Tel		82-2-380-2252
Fax		82-2-354-1078
Mobile	82-10-8011-1036

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
The fix is to install source packages: use argument type="source", 
including AFAICS as an argument to biocLite(). Or set
options(pkgType="source").

Simon: it is unclear to me what build this is, but could the default not 
be pkgType="source" for off-CRAN builds?  I don't think we should be 
expecting third parties to support architectures the CRAN build does not.

        
On Sun, 9 Dec 2007, ?? ???? wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Dec 9, 2007, at 3:02 AM, Prof Brian Ripley wrote:

        

            

      
      
      
    

        
It is the "experimental" Leopard quad-arch nightly build and yes,  
changing the default package type is a good idea. I'll look into this.

Thanks,
Simon

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    
3 days later

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Hi Simon,

        
Simon Urbanek wrote:

        
[...]

            

      
      
      
    

        
We are trying to help some Bioconductor users to use these nightly
builds in 64-bit mode.

I noticed that when I start them with R --arch=x86_64, 'sessionInfo()'
and 'version' still report i386 (this is with the latest R-2.6-branch
or R-devel builds for Leopard available at http://r.research.att.com/).

However, when I try to install and load a Bioconductor binary package,
I do get the same error as reported by Tae-Hoon:

  > library(Biostrings)
  Error: package 'Biostrings' is not installed for 'arch=x86_64'

so it seems that I'm really running R in x86_64 mode (and then the
error I get with library(Biostrings) is perfectly normal since the
BioC universal binaries don't support the x86_64 arch yet).

Also note that when I start R with --arch=ppc, 'sessionInfo()' and 'version'
report the powerpc arch. So why isn't it the case with the x86_64 arch?

Thanks!
H.

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Hi Herve,

        
On Dec 12, 2007, at 7:06 PM, Herve Pages wrote:

        

            

      
      
      
    

        
Yes - the platform is always i386 or powerpc since Mac OS X identifies  
as such (there is no 64-bit only Mac OS X).

The only reliable way of identifying 32-bit vs 64-bit (on any  
platform) is .Machine$sizeof.pointer

            

      
      
      
    

        
Yes, you are - see .Platform$r_arch

            

      
      
      
    

        
Because Mac OS X on PowerPC identifies itself as powerpc (and there is  
ppc-only Mac OS X). The same is true for --arch=ppc64.

I know that this is confusing, but this is the default. I could force  
the identifiers to be x86_64 and powerpc64 at build time (mainly  
because such platforms officially don't exist), but for now I have  
refrained from doing so. The Leopard 64-bit builds are experimental,  
so nothing is set in stone yet ...

Cheers,
Simon

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 13 Dec 2007, Simon Urbanek wrote:

        

            

      
      
      
    

        
I don't think so.  The R.version setting is coming from what configure 
identifies as the value: e.g. the 'arch' value is that of the C macro 
R_CPU.  The configure support files in R-devel have been updated, and do 
give x86_64 using a 64-bit compiler on iMac/Leopard.  I don't have a ppc 
Mac, so not know (nor care) what the value is there.

[...]

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Dec 13, 2007, at 12:18 PM, Prof Brian Ripley wrote:

        

            

      
      
      
    

        
Not for me (tonight's R-devel build):

 > R.version
                _
platform       i386-apple-darwin9.1.0
arch           i386
os             darwin9.1.0
system         i386, darwin9.1.0
status         Under development (unstable)
major          2
minor          7.0
year           2007
month          12
day            12
svn rev        43668
language       R
version.string R version 2.7.0 Under development (unstable)  
(2007-12-12 r43668)

 > .Platform$r_arch
[1] "x86_64"

 > .Machine$sizeof.pointer
[1] 8


AFAICS R_CPU comes from host_cpu which is always i386 or powerpc for  
Darwin:
In config.guess for Darwin: UNAME_PROCESSOR=`uname -p` and Mac OS X  
always reports i386 or powerpc, never anything else. This is different  
from Linux where the kernel will use x86_64 if in 64-bit mode.

As I was saying, we would have to override the platform string (and we  
can), but the official platform is i386-apple-darwin.

A possible work-around would be to modify R_CPU according to the  
compiler (which is what you were suggesting I presume) after we have  
run the checks on the compiler, but we don't do that right now (AFAICS).

Now for something related - right now it is a bit tedious to specify  
the 64-bit builds, because it means to essentially set all compilers  
to custom values. A convenient solution would be to invert the above  
and modify the compilers automatically if host_cpu is set manually to  
a 64-bit CPU (this is what some projects do e.g. GMP) basically by  
appending -arch x86_64 or -arch ppc64 to all compilers. I'm not 100%  
convinced of the usefulness, but it is a solution ...

Cheers,
Simon

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 13 Dec 2007, Simon Urbanek wrote:

        

            

      
      
      
    

        
On Linux it reports x86_64 if that is the kernel architecture, whatever 
mode it is in.  So an ix86 build of R on AMD64 reports arch=x86_64 unless 
you fiddle it.

On Solaris I get arch=sparc whatever the kernel is tuned for.

Someone has changed something in the last week (probably on our machine), 
as rebuilding today does give 'i386' as you found, but not on Dec 4.

            

      
      
      
    

        
Easily, set --build or --host on configure.  That's one reason why it is 
unreliable.

            

      
      
      
    

        
I was only reporting what I got, and I can't see how it happened so please 
discard the data point.  But if I want to change this I would specify 
--host (and it seems to work, at a quick test)

            

      
      
      
    

        
We could just introduce $(ARCH_FLAG), so e.g. CC is set to
@CC@ $(ARCH_FLAG).  There's a need to something like this elsewhere, e.g. 
-m32/-m64, -march or -mtune values.  Just provided there is a means to 
undo this with mixed compiler families (e.g. GNU/Sun Studio).