Skip to content

compiling packages for 64 bit architecture

8 messages · Christophe Dutang, Steve Lianoglou, Simon Urbanek

#
Hi all,

Using the following command to compile a package for 64bit  
architecture, I get a strange warning

dutangc at dtgMacBook(~/rmetrics/pkg)R CMD INSTALL --arch=x86_64  
randtoolbox
Warning: unknown option '--arch=x86_64'
* Installing to library '/Library/Frameworks/R.framework/Resources/ 
library'
* Installing *source* package 'randtoolbox' ...
checking for gcc... gcc
...
config.status: src/config.h is unchanged
** libs
** arch - x86_64
gfortran -arch x86_64   -fPIC  -g -O2 -c LowDiscrepancy.f -o  
LowDiscrepancy.o
gcc -arch x86_64 -std=gnu99 -I/Library/Frameworks/R.framework/ 
Resources/include -I/Library/Frameworks/R.framework/Resources/include/ 
x86_64  -I/usr/local/include    -fPIC  -g -O2 -c SFMT.c -o SFMT.o
gcc -arch x86_64 -std=gnu99 -I/Library/Frameworks/R.framework/ 
Resources/include -I/Library/Frameworks/R.framework/Resources/include/ 
x86_64  -I/usr/local/include    -fPIC  -g -O2 -c congruRand.c -o  
congruRand.o
gcc -arch x86_64 -std=gnu99 -I/Library/Frameworks/R.framework/ 
Resources/include -I/Library/Frameworks/R.framework/Resources/include/ 
x86_64  -I/usr/local/include    -fPIC  -g -O2 -c init.c -o init.o
...
gcc -arch x86_64 -std=gnu99 -dynamiclib -Wl,- 
headerpad_max_install_names -undefined dynamic_lookup -single_module - 
multiply_defined suppress -L/usr/local/lib -o randtoolbox.so  
LowDiscrepancy.o SFMT.o congruRand.o init.o knuthTAOCP2002.o  
randtoolbox.o runifInterface.o testrng.o version.o -L/Library/ 
Frameworks/R.framework/Resources/lib/x86_64 -lRlapack -L/Library/ 
Frameworks/R.framework/Resources/lib/x86_64 -lRblas -lgfortran - 
lgfortran -F/Library/Frameworks/R.framework/.. -framework R -Wl,- 
framework -Wl,CoreFoundation
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
  >>> Building/Updating help pages for package 'randtoolbox'
      Formats: text html latex example
** building package indices ...
* DONE (randtoolbox)

Everything is compiled correctly. In R64 GUI, the package is loaded  
successfully.

How could I get rid of this warning?

Furthermore, if I launch R GUI, the package could not better loaded  
any more on 32 bit architecture... I got
Error: package 'randtoolbox' is not installed for 'arch=i386'

How could I use both architecture at the same time (from different  
GUIs). I need to compare outputs of the halton function between the  
two architectures.

Thanks in advance

Christophe



--
Christophe Dutang
Ph.D. student at ISFA, Lyon, France
website: http://dutangc.free.fr
#
On Sep 20, 2009, at 3:59 PM, Christophe Dutang wrote:

            
The correct command is
R --arch x86_64 CMD INSTALL ...
(note that --arch is an argument of R *not* of INSTALL).
Yes, you replaced it.
You have to use --libs-only (see R-admin: 2.5 Sub-architectures).
First, do *not* use the directory of the package unless you cleaned it  
(important!!). Then you want something like
R --arch=i386 CMD INSTALL --libs-only randtoolbox

Cheers,
Simon
#
Le 20 sept. 2009 ? 23:11, Simon Urbanek a ?crit :
Thanks , I'll have a look at the subsection 2.5

Christophe
--
Christophe Dutang
Ph.D. student at ISFA, Lyon, France
website: http://dutangc.free.fr
1 day later
#
Thanks for the tips, it works now.

Since randtoolbox depends on rngWELL, which also has a configure file,  
I need to the following to compile randtoolbox for both architectures:
- for i386,
	- rm *.o  in rngWELL/src
	- R --arch=i386 CMD INSTALL --libs-only rngWELL
	- rm *.o  in randtoolbox/src
	- R --arch=i386 CMD INSTALL --libs-only randtoolbox
- for x86_64,
	- rm *.o  in rngWELL/src
	- R --arch=x86_64 CMD INSTALL --libs-only rngWELL
	- rm *.o  in randtoolbox/src
	- R --arch= x86_64 CMD INSTALL --libs-only randtoolbox

If I want to avoid to manually remove object files in src directory,  
can I use a makefile in this directory?

Do you advise me to install packages in a different directory than  
R_HOME/library using -l option?

Thanks in advance

Christophe
--
Christophe Dutang
Ph.D. student at ISFA, Lyon, France
website: http://dutangc.free.fr
#
Hi,
On Sep 22, 2009, at 1:36 AM, Christophe Dutang wrote:

            
Sure, why not? If it's not there, you can make one yourself, no? We  
can provide an example, if that's what you're after.

I'm not sure how to get R to run a custom Makefile tho (R-gurus: can  
you?)
I think this is a matter of personal taste. I just install all of my  
libs in the "system" directory, and don't specify a personal one, but  
then again: my os x box is just a single user machine.

-steve

--
Steve Lianoglou
Graduate Student: Computational Systems Biology
   |  Memorial Sloan-Kettering Cancer Center
   |  Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact
#
On Sep 22, 2009, at 1:36 AM, Christophe Dutang wrote:

            
I assume you mean for you personal debugging of the package - sure,  
but you could as well use just a shell script  ...

However, for real use you should not be installing from a directory in  
the first place - you should be using R CMD build to create the tar  
ball and then R CMD INSTALL for the archs - and you need no manual  
intervention for that. (The whole point of R not building all archs if  
you have configure or Makefile is exactly that it's hard to clean the  
unpacked tar ball after one arch has been built - in theory files  
could have been modified beyond repair so the only safe way to proceed  
is to remove everything and unpack it again.).
The main two options are system-wide installation (R_HOME/library) for  
users with admin rights or user-local installation (~/R/library/x.y  
where x.y is the R version). Those two are supported by R out of the  
box. Generally I don't recommend the latter on single-user machines,  
because people often forget about packages in one or the other  
location so it's common that you get package version mismatches which  
lead to all sorts of problems. On admin-maintained systems (good  
planning) it's usually not an issue, but it often is on personal  
machines.

Cheers,
Simon
1 day later