[Bioc-devel] Bioc 2.2 versus x86_64-only R 2.7 on OS X
Herve Pages
hpages at fhcrc.org
Thu Nov 1 21:37:13 CET 2007
Hi Anand,
I hope some Mac expert will be able to help you. Have you tried the R-SIG-Mac
mailing list? Because in the end, the problem you found is not strictly a
Bioconductor question but more generally about compiling R packages (that have
a configure script) for the x86_64 arch on Mac OS X.
Anyway, here are my 2 cents (continued below).
Anand C. Patel wrote:
> OK. In the process of running maSigPro on 30 arrays in an affyBatch (output
> from combineAffyBatch), my previously happy R 2.6 threw malloc errors --
> starting with an inability to allocate a vector of 1.3 gb. This happened on
> multiple occasions, and happened regardless of whether or not other data was
> cleared, OS X memory was free and available, etc. The last time it happened
> OS X had 3.4 gb of free physical memory . . .
You should be able to alloc a vector of 1.3GB. Have you reported this to R-devel
or R-SIG-Mac? For example, have you tried this:
x <- raw(2000000000)
in a fresh R session?
This works for me with a 32-bit R-2.6.0 on an Intel Mac Mini with only 2GB of RAM.
>
> So, I figured I'd compile a 64-bit version of R 2.7 for OS X 10.5. After some
> issues, that is now working. The last easily available 64-bit R for OS X is
> 2.5, and I wanted to use the newer packages from 2.6 (at least). R 2.6 won't
> compile in 64-bit mode with Quartz, but R 2.7 will.
>
> It is compiled specifically for x86_64, as I don't personally need it to run
> on all 4 possible architectures. I did this by declaring multiple flags at
> ./configure time:
>
> ./configure CC='gcc -arch x86_64' CXX='g++ -arch x86_64' \
> F77='gfortran -arch x86_64' FC='gfortran -arch x86_64' 'CFLAGS=-g -O3 -m64
> -I/readline/include -L/readline/lib' 'OBJCFLAGS=-g -O3 -m64
> -I/readline/include -L/readline/lib' 'LDFLAGS=-L/usr/local/lib' 'FFLAGS=-g -O3
> -m64 -I/readline/include -L/readline/lib ' 'CXXFLAGS=-g -O3 -m64
> -I/readline/include -L/readline/lib' 'FCFLAGS=-g -O3 -m64 -I/readline/include
> -L/readline/lib' \
> --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
I hope this syntax 'CFLAGS=...', 'OBJCFLAGS=...', etc... instead of CFLAGS='...',
OBJCFLAGS='...', etc... is correct (should be OK but...)
Also, the step-by-step guide on http://r.research.att.com/exp/ doesn't use any
of those args so I hope you know what you are doing.
>
> However, when I try to install bioc 2.2 packages, there is a significant
> problem. Most packages compile from source just fine. However, some of the
> core packages fail to compile because the packages themselves declare
> PKG_CFLAGS and this creates a conflict with the flags above. affy, affyio,
> and preprocessCore all do their own variation of the following:
It seems that only packages with a configure script are affected, is that right?
>
> (excerpt taken from affyio, but the other two do the same thing)
>
> configure: creating ./config.status
> config.status: creating src/Makevars
> ** libs
> gcc -arch x86_64 -std=gnu99 -I/R-devel/include -I/R-devel/include
> -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_ZLIB=1 -DHAVE_LIBPTHREAD=1 -DUSE_PTHREADS=1
> -I/sw/include -I/usr/local/include -arch ppc -arch ppc64 -arch i386 -arch
> x86_64 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
> -mmacosx-version-min=10.4 -fPIC -g -O3 -m64 -I/readline/include
> -L/readline/lib -c fread_functions.c -o fread_functions.o
> lipo: /var/tmp//ccdPcoay.out and /var/tmp//ccz02Cr2.out have the same
> architectures (x86_64) and can't be in the same fat output file
Have you tried to not use 'CFLAGS=-g -O3 -m64 -I/readline/include -L/readline/lib'
when you compile R. What does it do?
Note that if I use R-25-br-quad.tar.gz from http://r.research.att.com/exp/, then affyio compiles
with no problem:
creating ./config.status
creating src/Makevars
** libs
** arch - x86_64
gcc -arch x86_64 -std=gnu99 -no-cpp-precomp -I/Library/Frameworks/R.framework/Resources/include
-I/Library/Frameworks/R.framework/Resources/include/x86_64 -DHAVE_ZLIB=1 -I/usr/local/include
-D__NO_MATH_INLINES -fPIC -g -O2 -c read_abatch.c -o read_abatch.o
gcc -arch x86_64 -std=gnu99 -no-cpp-precomp -I/Library/Frameworks/R.framework/Resources/include
-I/Library/Frameworks/R.framework/Resources/include/x86_64 -DHAVE_ZLIB=1 -I/usr/local/include
-D__NO_MATH_INLINES -fPIC -g -O2 -c read_bpmap.c -o read_bpmap.o
(of course this is not the same affyio as yours, because I'm using R-2.5, so I get affyio 1.4.1
when I do biocLite("affyio", type="source"))
As for trying with a 64-bit R-2.7, I didn't have much luck when I tried to compile R:
Error: C stack usage is too close to the limit
:-(
Cheers,
H.
>
> I fixed this by extracting the packages, and individually changing the
> PKGS_CFLAGS line in the Makevars.in files in all 3 packages from:
> PKG_CFLAGS = @CFLAGS@
> to
> PKG_CFLAGS = -isysroot /Developer/SDKs/MacOSX10.4u.sdk
> -mmacosx-version-min=10.4
>
> I am overly aware that this is an ugly kludge. However, again using affyio as
> an example:
> configure: creating ./config.status
> config.status: creating src/Makevars
> ** libs
> gcc -arch x86_64 -std=gnu99 -I/R-devel/include -I/R-devel/include
> -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_ZLIB=1 -DHAVE_LIBPTHREAD=1 -DUSE_PTHREADS=1
> -I/sw/include -I/usr/local/include -isysroot /Developer/SDKs/MacOSX10.4u.sdk
> -mmacosx-version-min=10.4 -fPIC -g -O3 -m64 -I/readline/include
> -L/readline/lib -c fread_functions.c -o fread_functions.o
>
> and it successfully builds and installs.
>
> A glance at the problem and the instructions for Mac R building from
> R.research.att.com suggests that the root of the problem is that the
> architecture specification seems to need to happen at the level of the CC flag
> rather than the CFLAGS flag. When I tried to compile placing the architecture
> specification (-arch x86_64) in the CFLAGS (and other compiler flags) the R
> compile fails. Up front it looks like the downside of setting the packages up
> to automatically recognize OS X and compile to all 4 possible architectures.
> Is there an easier/better way to do this?
>
> Thanks,
> Anand C. Patel, MD
> Washington University School of Medicine
> acpatel at usa.net
>
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
More information about the Bioc-devel
mailing list