On Sep 4, 2009, at 11:27 PM, Adam D. I. Kramer wrote:
Simon,
Thanks for your comments; responses below.
On Fri, 4 Sep 2009, Simon Urbanek wrote:
Adam,
On Sep 4, 2009, at 5:52 PM, Adam D. I. Kramer wrote:
Hi Tony and Simon,
I was having this trouble today/yesterday and have been following
along on this thread. The solution I found was to add this to my
./configure:
LDFLAGS="-m64 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1/x86_64 -
lgfortran"
and
F77="gfortran -arch x86_64"
You should not touch LDFLAGS and besides F77 you'll also need to
set FC.
From configure --help:
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
...the gfortran library lives in a nonstandard directory,
Not really - it's the compiler library directory, i.e. where the
compiler looks for its internal libraries. It is never used
explicitly. The problem is that you're mixing compilers - you have a
Leopard gfortran (see my response to John - you have the same problem)
and SL gcc. That is not recommended and is likely to break in more
places.
which is why I put the -L there... so I then moved -lgfortran to
LIBS='-lgfortran' and things broke in the same way, as did moving
the -L...-lgfortran there. Both of these need to be passed to the
linker when mixing C/Fortran code.
It also throws the error "Maybe check LDFLAGS for paths to Fortran
libraries?" which is what tipped me off to the fact that I should
provide a link to the Fortran libraries in LDFLAGS. If this is
incorrect, please let me know where to put them instead (and
consider updating the configure script).
You should get a working gfortran instead - this is a problem in your
setup, not configure. Unfortunately Apple has broken fortran in the
gcc-4.2 tree so I don't have a working gfortran binary for Xcode 3.2,
so please use the gfortran 4.2.3 from CRAN.
...this gets me through the "can't make mixed C/Fortran code"
errors. However, through one hoop of fire and I'm confronted by
another:
checking for iconv.h... yes
checking for iconv... no
checking for iconvlist... no
configure: error: --with-iconv=yes (default) and a suitable iconv
is not
available
...this strikes me as odd. The relevant lines from the config.log
file are:
configure:39212: gcc -std=gnu99 -o conftest -O3 -fopenmp -
mtune=native -m64 -m64 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1/
x86_64 -lgfortran conftest.c -lm >&5
conftest.c: In function 'main':
conftest.c:189: warning: passing argument 1 of 'libiconvlist' from
incompatible pointer type
Undefined symbols:
"_libiconvlist", referenced from:
_main in cc2XgkAg.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
However:
swiss:R-2.9.2$ nm /usr/lib/libiconv.dylib | grep _libiconvlist
00008807 T _libiconvlist
...I'm not sure where else configure could be trying to find
libiconv,
check /usr/local/lib that is the most common problem area ...
I had, and there was no libiconv there.
I eventually solved this problem by upgrading fink
Oh, fink? Ok, that explains it all :).
to the 64bit version and installing libiconv and adding CPPFLAGS="-I/
sw/include" and adding -L/sw/lib to LDFLAGS, forcing it to link
against the new library. It seems like the Apple libraries should
serve the purpose, but for whatever reason they did not.
They do, but fink overrides the look up sequence since most of its
stuff is incompatible with the system versions (which is why it causes
such a havoc).
Cheers,
Simon
My current problem is that, during make, R complains about the
lapack.so
file it has compiled from my lapack libraries (I configured with
--with-lapack="-L/usr/local -llapack -lptf77blas -lcblas -lpthread -
latlas"
and a similar --with-blas):
Warning in solve.default(rgb) :
unable to load shared library '/Volumes/Tubby2/nobackup/R-2.9.2/
modules//lapack.so':
dlopen(/Volumes/Tubby2/nobackup/R-2.9.2/modules//lapack.so, 6):
Symbol not found: _cblas_cdotc_sub
Referenced from: /Volumes/Tubby2/nobackup/R-2.9.2/modules//lapack.so
Expected in: flat namespace
in /Volumes/Tubby2/nobackup/R-2.9.2/modules//lapack.so
Error in solve.default(rgb) : lapack routines cannot be loaded
Error: unable to load R code in package 'grDevices'
Execution halted
...that said, I understand that --with-lapack is "not recommended"
in the
admin manual, so I'm pretty much on my own here, but I'd be
interested if
you have an idea or two about what might be going on.
_cblas_cdotc_sub is
indeed in my lapack.a file (but not the lapack.so file R refers to),
and I
can use _cblas_cdotc if I write some simple c code and link it against
lapack using the same flags as noted above.
My interest, really, is in whether ATLAS's LAPACK-tuning system
(which is
pretty new) actually leads to speed improvements in R. So, I don't
desperately need to use it, but am still concerned that a compile
that used
to run smoothly no longer does.
--Adam
Cheers,
Simon
but
running "locate libiconv" shows versions in
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/ also, which also show
_libiconvlist
when I nm them.
Any suggestions? I'm not sure how to further debug this...the
symbols are
there.
Cordially,
Adam
Hi Simon,
I think that you might have resolved my issue. I did not specify
the arch,
so I will try that and let everyone know if that works.
Cheers,
--Tony
On Thu, Sep 3, 2009 at 4:11 PM, Simon Urbanek
<simon.urba...@r-project.org>wrote:
Tony,
On Sep 3, 2009, at 6:14 PM, Tony Chiang wrote:
So I am trying to configure and build the latest of R-devel on
one of the
new Macbook Pro's running Snow leopard. I have installed the
latest
X-Code
tools (downloaded from the Apple Site) and have gcc installed:
gcc --versioni686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple
Inc. build
5646)
So as I am trying to configure, I get this error message:
What is the exact configure command you're running? I suspect
that your
problem is a 32-bit vs 64-bit mismatch, because SL changed the
gcc default
to 64-bit whereas the gfortran default is 32-bit, so you have to
make sure
your archs match (depending on which you actually want to build)
- ideally
you should specify -arch for all compilers (as the CRAN binary
does - also
see the FAQ).
Cheers,
Simon
...cut...
checking for Fortran 77 libraries of gfortran... -L/usr/local/
lib
-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3
-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../.. -
lgfortranbegin
-lgfortran
checking how to get verbose linking output from gcc -
std=gnu99... -v
checking for C libraries of gcc -std=gnu99... -lcrt1.10.6.o
-L/usr/local/lib -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
-L/usr/lib/i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple-
darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. -lSystem
checking for dummy main to link with Fortran 77 libraries... rm:
conftest.dSYM: is a directory
none
checking for Fortran 77 name-mangling scheme... rm:
conftest.dSYM: is a
directory
unknown
configure: WARNING: unknown Fortran name-mangling scheme
checking whether gfortran appends underscores to external
names...
unknown
configure: error: cannot use Fortran
I have not seen any messages quite like this on the mailing
list. What is
pretty strange is the conftest.dSYM needs to be removed (?) for
some
reason
but is a directory. Any ideas or suggestions on how to resolve
this?
Best,
--Tony
[[alternative HTML version deleted]]
_______________________________________________
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
_______________________________________________
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
