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