On Jan 26, 2010, at 15:57 , Kasper Daniel Hansen wrote:
On Jan 26, 2010, at 15:24 PM, cstrato wrote:
Dear Simon,
Meanwhile I have tried to install xps:
$ R CMD INSTALL -l ~/Library/R/2.10/library xps_1.7.4.tar.gz
* installing *source* package 'xps' ...
checking for gcc... gcc-4.2 -arch i386 -std=gnu99
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc-4.2 -arch i386 -std=gnu99 accepts -g... yes
checking for gcc-4.2 -arch i386 -std=gnu99 option to accept ANSI
C... none needed
checking how to run the C preprocessor... gcc-4.2 -arch i386 -
std=gnu99 -E
checking for gcc... (cached) gcc-4.2 -arch i386 -std=gnu99
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc-4.2 -arch i386 -std=gnu99 accepts -g...
(cached) yes
checking for gcc-4.2 -arch i386 -std=gnu99 option to accept ANSI
C... (cached) none needed
found ROOT version 5.24/00 in directory /Users/rabbitus/ROOT/root
** libs
** arch - i386
As you can see it compiles using the wrong architecture:
library(xps)
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '/Users/rabbitus/Library/R/2.10/
library/xps/libs/i386/xps.so':
dlopen(/Users/rabbitus/Library/R/2.10/library/xps/libs/i386/xps.so,
6): no suitable image found. Did find:
/Users/rabbitus/Library/R/2.10/library/xps/libs/i386/xps.so:
mach-o, but wrong architecture
Error: package/namespace load failed for 'xps'
In my file "config.in" I have the following lines:
# See "Writing R Extensions"
: ${R_HOME=`R RHOME`}
if test -z "${R_HOME}"; then
echo "could not determine R_HOME"
exit 1
fi
CC=`"${R_HOME}/bin/R" CMD config CC`
CFLAGS=`"${R_HOME}/bin/R" CMD config CFLAGS`
AC_PROG_CPP
AC_PROG_CC
Thus I assume that I need to use 64 bit R so that the flags are set
correctly. Is this correct?
This is probably because you are using the CRAN binary which is a
universal binary. Specifically this means that it will try to
compile the package for all architectures,
Nope - see above - it has a configure. He's simply running the wrong
architecture. With the proper binary
R --arch=x86_64 CMD INSTALL ...
will do the trick.
Cheers,
Simon
which will fail because ROOT is only installed for one of the
architectures. This will happen for any package with C code you
install from source, try picking your favorite R package with C code
(say, preprocessCore), set options(pkgType = "source") and install
it using biocLite. You will see several compilation runs.
There are a hack to fix this, and there may be an official way to
compile a package only for a specific architecture, which I don't
know about.
The hack: inside (this is for 2.11)
/Library/Frameworks/R.framework/Versions/2.11/Resources/bin/exec/
you will see a list of subdirectories describing what architecture
you have R compiled for. If you remove all the other architectures
aside from x86_64 it might work. This might mess up your R.app
though.
Alternatively you could compile R from source, only for one
architecture. This is what I do.
Kasper
If yes, can I use:
http://r.research.att.com/R-GUI-5548-2.10-leopard-Leopard64.dmg
or do I need to build 64 bit R from source?
Best regards
Christian
Simon Urbanek wrote:
On Jan 25, 2010, at 5:34 PM, cstrato wrote:
Dear Simon,
Thank you, with this version I could finally compile ROOT as 64
bit.
Now I have one more question:
When I do "R CMD Install xps.tar.gz" which now depends on 64 bit
ROOT, do I need to install the 64 bit version of R or can I use
the current R version?
I have no idea since I don't know your package. If you *link* to
ROOT then yes, you have to use 64-bit R to load 64-bit code.
(Linking in itself can be quite interesting given the flags ROOT
uses, so your journey may not end there ;)).
Cheers,
Simon
Best regards
Christian
Simon Urbanek wrote:
On Jan 25, 2010, at 15:03 , cstrato wrote:
Dear Simon,
Thank you for your suggestions, which I have just tried. Sadly
the error remains the same.
The problem seems to be that for some reason "gfortran-4.2-5564-
darwin9.tar.gz" does not have a "/usr/lib/gcc/i686-apple-
darwin9/4.2.1/x86_64" directory containing libgfortranbegin.a.
For this reason the 64 bit version of libgfortranbegin.a is not
installed in the corresponding directory x86_64 which contains
only libgcc.a etc.
Oh ... that's a surprise - it should be there, sorry. Ok, so
please use the more recent 5566 build:
http://r.research.att.com/tools/gfortran-4.2-5566-darwin9.tar.gz
that one has the x86_64 files - I checked:
ginaz:~$ curl -s -S http://r.research.att.com/tools/gfortran-4.2-5566-darwin9.tar.gz
| tar fvtz - | grep gfortran.a
-rw-r--r-- root/wheel 3592608 2008-12-24 14:51:33 usr/lib/gcc/
i686-apple-darwin9/4.2.1/libgfortran.a
-rw-r--r-- root/wheel 3870032 2008-12-24 14:51:33 usr/lib/gcc/
powerpc-apple-darwin9/4.2.1/libgfortran.a
-rw-r--r-- root/wheel 5002152 2008-12-24 14:51:33 usr/lib/gcc/
i686-apple-darwin9/4.2.1/x86_64/libgfortran.a
(Ideally you should install Xcode 3.1.2 for this since that is
where the 5566 build comes from, but it will probably work even
if the builds don't match perfectly).
Cheers,
Simon
You can see this by double-clicking on "gfortran-4.2-5564-
darwin9.tar.gz" when located in some directory.
In contrast, "gfortran-4.2.3.dmg" did install
libgfortranbegin.a in the "/usr/local/lib/gcc/i686-apple-
darwin9/4.2.1/x86_64" directory.
Could you please check or tell me what the reason might be?
I have installed it using:
$ gunzip gfortran-4.2-5564-darwin9.tar.gz
$ sudo tar -xvf gfortran-4.2-5564-darwin9.tar -C /
Best regards
Christian
Simon Urbanek wrote:
On Jan 24, 2010, at 3:28 PM, cstrato wrote:
Dear Kasper,
You are right. Since ROOT supports the CC, CXX, F77 and LD
flags I did:
./configure macosx64 --with-cxx="/usr/bin/g++-4.2 -arch
x86_64" --with-f77="/usr/bin/gfortran-4.2 -arch x86_64"
You don't really need the override - it works without and they
add -m64 anyway so the -arch gets essentially ignored.
The error was still the same:
i686-apple-darwin9-g++-4.2.1: libgfortran.dylib: No such file
or directory
However, when I replaced in the Makefile.macosx64:
F77LIBS := $(shell $(F77) -m64 -print-file-
name=libgfortran.dylib)
F77LIBS += $(shell $(F77) -m64 -print-file-
name=libgfortranbegin.a)
with:
F77LIBS := $(shell $(F77) -m64 -print-file-
name=libgfortranbegin.a)
You found the right spot but your fix is wrong - just remove
the two lines, they are superfluous and only cause trouble.
the error disappeared, and I could finish the compilation.
However, now I got a link-error:
ld warning: in /usr/lib/gcc/i686-apple-darwin9/4.2.1/
libgfortranbegin.a, file is not of required architecture
Undefined symbols:
"_main", referenced from:
start in crt1.10.5.o
Your'e getting the 32-bit version (of the wrong file - see
above). It should really be ../4.2.1/x86_64/lib...
I am not sure what this error means since Makefile.macosx64
contains:
F77FLAGS = -m64 -std=legacy
Could it be that libgfortranbegin.a can only be used for
32bit compilation?
No, you're picking the wrong one - there is one for each
architecture.
Furthermore, I still have the question (and hopefully Simon
will answer it):
Why does gfortran-4.2-5564-darwin9.tar.gz not contain any
libgfortran.dylib files?
Because it's using a static library.
Interestingly, when googling "/usr/lib/libgfortran.dylib" I
get the answer that NO results were found, while googling "/
usr/local/lib/libgfortran.dylib" gives many results. Thus it
seems that there will never be any libgfortran.dylib in "/usr/
lib/"!?
Nope - OS X has no Fortran by default.
Cheers,
Simon
I must admit that I do not understand this issue.
Best regards
Christian
Kasper Daniel Hansen wrote:
On Jan 23, 2010, at 8:37 AM, cstrato wrote:
Dear Kasper,
Thank you for your suggestion, I did indeed use gcc 4.0.
Since gcc_select does no longer exist on Leopard I had to do:
cd /usr/bin
sudo ln -s gcc-4.2 gcc
sudo ln -s g++-4.2 g++
sudo ln -s gcov-4.2 gcov
I am not sure this is advisable in general. When I compile
stuff with gcc-4.2 I usually explicitly set
CC=/usr/bin/gcc-4.2
when I run configure. For example, my entire configure line
for R on my macbook is
../${SRCDIR}/configure SHELL='/bin/bash' \
CC="/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99" \
CFLAGS="-g -O2 -std=gnu99 -march=nocona" \
CXX="/usr/bin/g++-4.2 -arch x86_64" \
CXXFLAGS="-g -O2 -march=nocona" \
OBJC="/usr/bin/gcc-4.2 -arch x86_64" \
F77="/usr/bin/gfortran-4.2 -arch x86_64" \
FFLAGS="-g -O2 -march=nocona" \
FC="/usr/bin/gfortran-4.2 -arch x86_64" \
FCFLAGS="-g -O2 -march=nocona" \
--x-includes=/usr/X11/include --x-libraries=/usr/X11/
lib \
--with-system-zlib \
--with-blas='-framework vecLib' --with-lapack
Of course this requires that ROOT uses the CC/CFLAGS macros,
but that should be pretty standard if it uses autoconf.
Sadly, compiling ROOT resulted still in the same error:
i686-apple-darwin9-g++-4.2.1: libgfortran.dylib: No such
file or directory
When I check the location for gfortran-4.2.3.dmg I get:
$ cd /usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../../
x86_64
$ ls -al
total 32
drwxrwxr-x 6 root wheel 204 Jan 21 20:26 .
drwxr-xr-x 35 root wheel 1190 Jan 21 20:26 ..
lrwxr-xr-x 1 root wheel 26 Jan 21 20:26 libgfortran.
2.0.0.dylib -> ../libgfortran.2.0.0.dylib
lrwxr-xr-x 1 root wheel 23 Jan 21 20:26 libgfortran.
2.dylib -> libgfortran.2.0.0.dylib
lrwxr-xr-x 1 root wheel 16 Jan 21 20:26 libgfortran.a
-> ../libgfortran.a
lrwxr-xr-x 1 root wheel 23 Jan 21 20:26
libgfortran.dylib -> libgfortran.2.0.0.dylib
This means that /usr/local/bin does contain
libgfortran.dylib whereas /usr/bin does not contain any of
these files or links.
Does this mean that gfortran-4.2.3.dmg does contain these
file for libgfortran.dylib while gfortran-4.2-5564-
darwin9.tar.gz does not contain these files?
How do I get libgfortran.dylib?
Simon might be able to answer this better, but the general
idea is that the
gfortran-4.2-5564-darwin9.tar.gz
installs into /usr/bin
gfortran-4.2.3.dmg
installs into /usr/local/bin. There is some logic here, the
way I think about it is that the former is a direct
extension of the Apple build.
I would start from scratch, which means remove all traces of
both gfortrans, install the 5564-tarball and then set the
various macros as I have set it above for R (your exact
values may of course be different depending on what machine
etc. you are using).
Kasper
BTW, I must apologize to Simon. On his website he lists the
commands how to install gfortran.tar.gz, but in the Tiger
section, so I did miss it. Nevertheless it would still be
helpful for Mac users to know how to uninstall it:
$ tar -tf gfortran.tar | sort -r | (cd /; xargs -p -n 1 rm -
d)
Best regards
Christian
Kasper Daniel Hansen wrote:
Remember that Apple has two version of GCC on Leopard: 4.0
and 4.2. You are using 4.0, you might want to switch to
4.2. In Tiger there used to be gcc_select (or select_gcc)
that let you choose between 3.x and 4.0, I don't remember
if that is still around on Leopard.
The error seems to indicate that you need 4.2 in order to
use Simon's gfortran.
Kasper
On Jan 22, 2010, at 16:04 PM, cstrato wrote:
Dear Simon,
Thank you for this information.
Now I have installed gfortran-4.2-5564-darwin9.tar.gz on
Leopard and tried to compile ROOT again, but this time I
got the following error:
g++ -dynamiclib -single_module -undefined dynamic_lookup -
install_name @rpath/libminicern.so -O2 -m64 -o lib/
libminicern.so misc/minicern/src/cernlib.o -ldl misc/
minicern/src/hbook.o misc/minicern/src/kernlib.o misc/
minicern/src/zebra.o libgfortran.dylib /usr/lib/gcc/i686-
apple-darwin9/4.2.1/libgfortranbegin.a
i686-apple-darwin9-g++-4.0.1: libgfortran.dylib: No such
file or directory
I know that this is not necessarily an R-related question
but I would greatly appreciate your help if possible (at
least it is a Mac- and somehow a BioC-related question).
When I have tried to compile ROOT with gfortran-4.2.3.dmg
I got the following error:
gfortran -O2 -m64 -o bin/g2root main/src/g2root.o -Llib
lib/libminicern.so /usr/local/lib/gcc/i686-apple-
darwin8/4.2.3/../../../x86_64/libgfortran.dylib /usr/
local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64/
libgfortranbegin.a -lm -Wl,-rpath,@loader_path/../lib -
pthread -ldl
ld: -rpath can only be used when targeting Mac OS X 10.5
or later
As you can see gfortran-4.2.3 could find
libgfortran.dylib at:
/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../../
x86_64/libgfortran.dylib while gfortran-4.2.4 could not
find libgfortran.dylib.
Thus maybe I did make a mistake when installing
gfortran-4.2.4. Here is what I did:
$ gunzip gfortran-4.2-5564-darwin9.tar.gz
$ sudo tar -xvf gfortran-4.2-5564-darwin9.tar -C /
$ sudo ln -s /usr/bin/gfortran-4.2 /usr/bin/gfortran
Do you know what I need to do so that libgfortran.dylib
can be found?
P.S.:Since many Mac users are no Unix experts please
allow me to suggest to place on your website the commands
to install/uninstall gfortran. I have found the following
website, which told me how to install gfortran and how I
could uninstall it:
http://www.webmo.net/support/fortran_osx.html
Thank you in advance.
Best regards
Christian
Simon Urbanek wrote:
On Jan 21, 2010, at 15:56 , cstrato wrote:
Dear Simon,
One more question:
I have just unzipped gfortran-4.2-5564-darwin9.tar.gz.
The version gives:
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /Builds/gcc/gcc_42-5564/build/obj/src/
configure --disable-checking --enable-werror --prefix=/
usr --mandir=/usr/share/man --enable-languages=c,objc,c+
+,obj-c++,fortran --program-transform-name=/^[cg][^.-]*
$/s/$/-4.2/ --with-gxx-include-dir=/usr/include/c++/
4.0.0 --with-slibdir=/usr/lib --build=i686-apple-
darwin9 --host=i686-apple-darwin9 --target=i686-apple-
darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5564)
This means that this version seems to be older than the
one I am using now?
No, that is GNU Fortran 4.2.4 that I was referring to.
The "gcc version 4.2.1" comes from Apple's Xcode 3.1
gcc-4.2 branch since that is what they define - it just
adds Fortran support to the existing gcc 4.2.1 branch of
Apple that you installed as Xcode. However, the Fortran
part is merged from the GNU Fortran 4.2.4 release -
hence I refer to it as 4.2.4.
Cheers,
Simon
Simon Urbanek wrote:
On Jan 21, 2010, at 14:47 , cstrato wrote:
Dear all,
I have the following problem:
My Bioconductor package xps requires both R and ROOT,
whereby I compile ROOT usually from source. Until now
this has not been a problem since I do all my
development on Tiger. However, now I wanted to
compile ROOT on Leopard but failed since my gfortran
compiler is too old, see:
http://root.cern.ch/phpBB2/viewtopic.php?t=9721&sid=003b01ddb64f33dbe0c74651ee089c34
To solve the problem I should upgrade to the latest
version coming with gcc-4.4 in Fink.
I would advise against that - using gcc from Fink
usually calls for a disaster. The real solution is to
fix their flags, but that's another story ...
Thus my question is:
Can I also use this version for R or do I need to use
the version downloaded from att?
I would recommend using the Leopard gfortran 4.2.4 for
Xcode 3.1.x from the Mac devel page
http://r.research.att.com/tools/
which I assume is what you meant by the latter.
Cheers,
Simon
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
