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

Simon Urbanek simon.urbanek at r-project.org
Sun Sep 6 04:04:45 CEST 2009

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  

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


> 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