[R-SIG-Mac] Building R-devel from Source on Snow Leopard

Adam D. I. Kramer adik at ilovebacon.org
Sat Sep 5 05:27:36 CEST 2009 

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, 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).

>> ...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 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.

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.urbanek at 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 at stat.math.ethz.ch
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
>> 
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

More information about the R-SIG-Mac mailing list