[R-SIG-Mac] 64-bit build from source ... 64bit readline oddity solved; libiconv now solved

Simon Urbanek simon.urbanek at r-project.org
Sun Jul 26 16:43:54 CEST 2009


Kasper,

On Jul 26, 2009, at 12:35 AM, Kasper Daniel Hansen wrote:

> I am building a 64bit version of R using only Xcode 3.1.2 as well as  
> the gfortran that Simon provides. This is on OS X 10.5.7. It is an  
> old installation, but I have only installed very few programs from  
> source (and have never used fink nor darwinports), like graphviz and  
> similar non-system-"like" programs. I have never had any problems  
> with readline or iconv.
>
> I also have the i386 message on startup, but my sizeof.pointer is 8.
>
> My otool output is
>
> grue:~/Work/readbias/paper/> otool -L /Library/Frameworks/ 
> R.framework/Versions/2.10/Resources/lib/libR.dylib
> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ 
> libR.dylib:
> 	/Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ 
> libR.dylib (compatibility version 2.10.0, current version 2.10.0)
> 	/Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ 
> libRblas.dylib (compatibility version 0.0.0, current version 0.0.0)
> 	/usr/local/lib/libgfortran.2.dylib (compatibility version 3.0.0,  
> current version 3.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/ 
> CoreFoundation (compatibility version 150.0.0, current version  
> 476.18.0)
> 	/usr/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0,  
> current version 5.2.0)
> 	/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current  
> version 36.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
> version 111.1.4)
> 	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current  
> version 7.0.0)
> 	/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
> current version 1.0.0)
>
> Hmm, I am wondering why it is linking to libgxx_s.1.dylib in /usr/ 
> local/lib and not in /usr/lib, and similar with libreadline. Could  
> that be leftovers from an old GCC from Simon? Or an old(er) R  
> install from the CRAN binary? I certainly never compiled readline  
> myself.
>

You can use either the CRAN gfortran (FSF build) in which case you'll  
get /usr/local/lib/libg* or you can use the gcc-4.2 add-on fortran  
which doesn't use /usr/local (as the instructions say you must remove  
the CRAN one if you want to use it). For my 64-bit build I'm using the  
latter since it seems more clean.
As for readline - there is no readline on OS X (for licensing reasons  
- it uses libedit instead), so you must use your own if you want it.  
You could use a static build to avoid the /usr/local dependency. (For  
CRAN R we just move it inside R and change the path to it).

Cheers,
Simon


>
> On Jul 25, 2009, at 17:56 , Vincent Carey wrote:
>
>> Thanks, Jan.  Here's the output of otool for my new libR
>>
>> bash-3.2$ otool -L libR.dylib
>> libR.dylib:
>>       libR.dylib (compatibility version 2.10.0, current version  
>> 2.10.0)
>>       /usr/local/lib/libreadline.6.0.dylib (compatibility version
>> 6.0.0, current version 6.0.0)
>>       /usr/lib/libiconv.2.dylib (compatibility version 7.0.0,
>> current version 7.0.0)
>>       libRblas.dylib (compatibility version 0.0.0, current version  
>> 0.0.0)
>>       /usr/local/lib/libgfortran.2.dylib (compatibility version
>> 3.0.0, current version 3.0.0)
>>       /System/Library/Frameworks/CoreFoundation.framework/Versions/ 
>> A/CoreFoundation
>> (compatibility version 150.0.0, current version 476.18.0)
>>       /usr/lib/libicucore.A.dylib (compatibility version 1.0.0,
>> current version 36.0.0)
>>       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>> current version 111.1.4)
>>       /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>>
>> Any obvious problems?
>>
>> Simon's binaries have been great; I am just trying the source build  
>> to
>> get more rapid access
>> to changes to devel.
>>
>> One item that may be noteworthy -- for the new build,
>>
>>> sessionInfo()
>> R version 2.10.0 Under development (unstable) (2009-07-24 r48993)
>> i386-apple-darwin9.7.0
>>
>> locale:
>> [1] C
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>> .Machine$sizeof.pointer
>> [1] 8
>>
>> what must be done to get the i386- prefix corrected?
>>
>>
>> On Sat, Jul 25, 2009 at 8:19 PM, Jan de  
>> Leeuw<deleeuw at stat.ucla.edu> wrote:
>>> I am using
>>>
>>> configure --with-aqua --with-blas='\''-framework vecLib'\'' --with- 
>>> lapack
>>> --prefix=/usr/local/R --disable-R-framework --with-readline --with- 
>>> cairo
>>> --enable-memory-profiling --enable-R-shlib --x-includes=/usr/X11R6/ 
>>> include
>>> --x-libraries=/usr/X11R6/lib --build=x86_64-apple-darwin10
>>> --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
>>>
>>> with OS X 10.6 and a GNU svn build of gcc-4.2 and gfortran-4.2. The
>>> resulting R has the quartz device as well, but cannot be used  
>>> directly with
>>> R.app. It also builds with the gcc-4.2 that comes with Xcode 3.2,  
>>> which I
>>> use for OBJC anyway, and maybe with Simon's gfortran (haven't  
>>> tried). Of
>>> course this is not a universal binary. I don't think 10.6 or Xcode  
>>> 3.2 are
>>> essential.
>>>
>>> My C, CXX, F, FC flags are
>>>
>>> -m64 -O3 -fopenmp -mtune=native
>>>
>>> and my LDFLAGS are
>>>
>>> -m64 -fopenmp
>>>
>>> For otool -L libR.dylib I get
>>>
>>> libR.dylib:
>>>       libR.dylib (compatibility version 2.10.0, current version  
>>> 2.10.0)
>>>       /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
>>> (compatibility version 1.0.0, current version 268.0.0)
>>>       /usr/local/lib/libintl.8.dylib (compatibility version 9.0.0,  
>>> current
>>> version 9.2.0)
>>>
>>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ 
>>> CoreFoundation
>>> (compatibility version 150.0.0, current version 549.0.0)
>>>       /usr/local/lib/libreadline.6.0.dylib (compatibility version  
>>> 6.0.0,
>>> current version 6.0.0)
>>>       /usr/lib/libicucore.A.dylib (compatibility version 1.0.0,  
>>> current
>>> version 40.0.0)
>>>       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
>>> current
>>> version 123.0.0)
>>>       /usr/local/lib/libiconv.2.dylib (compatibility version  
>>> 7.0.0, current
>>> version 7.0.0)
>>>
>>> Of course cairo, tcltk, jpeg, png, ... use additional stuff from / 
>>> usr/local.
>>>
>>> Why am I using this instead of Simon's excellent work ? I have no  
>>> idea. It
>>> feels a bit embarrassing.
>>>
>>>
>>> On Jul 25, 2009, at 16:32 , Vincent Carey wrote:
>>>
>>>> i'm aware of the r.research.att.com site -- i am working with  
>>>> what i
>>>> believe to be a relatively clean (out of the box
>>>> only a couple of weeks, some fink extensions) macosx 10.5.7 with  
>>>> Xcode
>>>> 3.1.2
>>>>
>>>> i won't deny that it is messed up but are there any ways of stating
>>>> minimal conditions
>>>> on the state of OSX needed to get a good 64 bit build?  would xcode
>>>> 3.1.3 make a big difference?
>>>> looks like something much earlier is adequate at your place.
>>>>
>>>> thanks
>>>>
>>>> On Sat, Jul 25, 2009 at 6:06 PM, Simon
>>>> Urbanek<simon.urbanek at r-project.org> wrote:
>>>>>
>>>>> Vince,
>>>>>
>>>>> On Jul 25, 2009, at 5:04 PM, Vincent Carey wrote:
>>>>>
>>>>>> now it seems that by using gcc-4.2 to build libiconv in a non- 
>>>>>> central
>>>>>> place and using
>>>>>> DYLD_LIBRARY_PATH to find it, and using gcc-4.2 to compile R,  
>>>>>> all is
>>>>>> well.
>>>>>>
>>>>>
>>>>> FWIW  suspect that your system is pretty badly messed up with  
>>>>> all the
>>>>> 3rd-party stuff you installed, because our 64-bit binaries don't  
>>>>> need any
>>>>> of
>>>>> this... see
>>>>> http://r.research.att.com/
>>>>>
>>>>> Also note that messing with DYLD_LIBRARY_PATH is really  
>>>>> dangerous and
>>>>> causes
>>>>> a lot of problems since it overrides *all* system path searches  
>>>>> (unlike
>>>>> LD_LIBRARY_PATH on Linux).
>>>>>
>>>>> Cheers,
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>>> On Sat, Jul 25, 2009 at 6:39 AM, Vincent
>>>>>> Carey<stvjc at channing.harvard.edu> wrote:
>>>>>>>
>>>>>>> The solution to the readline problem was to remove all  
>>>>>>> conflicting
>>>>>>> libreadline.* on
>>>>>>> the system.  However, now similar problems are cropping up with
>>>>>>> libiconv
>>>>>>>
>>>>>>> you should 'make docs' now ...
>>>>>>> building/updating package metadata ...
>>>>>>> dyld: lazy symbol binding failed: Symbol not found:  
>>>>>>> _libiconv_open
>>>>>>> Referenced from:
>>>>>>> /Users/stvjc/ExternalSoft/R-devel/lib/x86_64/libR.dylib
>>>>>>> Expected in: dynamic lookup
>>>>>>>
>>>>>>> installing a fresh 32/64-bit libiconv and removing all  
>>>>>>> conflicting
>>>>>>> versions has not helped.
>>>>>>>
>>>>>>> On Fri, Jul 24, 2009 at 3:54 PM, Vincent
>>>>>>> Carey<stvjc at channing.harvard.edu> wrote:
>>>>>>>>
>>>>>>>> this build from a very recent svn checkout of devel is  
>>>>>>>> incomplete.  it
>>>>>>>> fails
>>>>>>>> while trying to build base with the same error as occurs here
>>>>>>>>
>>>>>>>> bash-3.2$ bin/R
>>>>>>>> dyld: Symbol not found: _rl_basic_word_break_characters
>>>>>>>> Referenced from:
>>>>>>>> /Users/stvjc/ExternalSoft/R-devel/lib/x86_64/libR.dylib
>>>>>>>> Expected in: dynamic lookup
>>>>>>>>
>>>>>>>> Trace/BPT trap
>>>>>>>>
>>>>>>>> i built readline 6.0 from source with the -arch x86_64 switch  
>>>>>>>> on gcc
>>>>>>>> and configure
>>>>>>>> worked ok.  i think the symbol exists
>>>>>>>>
>>>>>>>> nm /usr/local/lib/libreadline.6.0.dylib | grep break
>>>>>>>> 000000000002b500 D _rl_basic_word_break_characters
>>>>>>>> 000000000002b4f0 D _rl_completer_word_break_characters
>>>>>>>> 000000000002b4e8 D _rl_completion_word_break_hook
>>>>>>>>
>>>>>>>> help!  the past few days have been nothing but glitches and  
>>>>>>>> bugs...
>>>>>>>>
>>>>>>>> --
>>>>>>>> Vincent Carey, PhD
>>>>>>>> Biostatistics, Channing Lab
>>>>>>>> 617 525 2265
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Vincent Carey, PhD
>>>>>>> Biostatistics, Channing Lab
>>>>>>> 617 525 2265
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Vincent Carey, PhD
>>>>>> Biostatistics, Channing Lab
>>>>>> 617 525 2265
>>>>>>
>>>>>> _______________________________________________
>>>>>> R-SIG-Mac mailing list
>>>>>> R-SIG-Mac at stat.math.ethz.ch
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Vincent Carey, PhD
>>>> Biostatistics, Channing Lab
>>>> 617 525 2265
>>>>
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> R-SIG-Mac at stat.math.ethz.ch
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>
>>>
>>> ===
>>> Jan de Leeuw; Distinguished Professor and Chair, UCLA Department of
>>> Statistics;
>>> Director: UCLA Center for Environmental Statistics (CES);
>>> Editor: Journal of Multivariate Analysis, Journal of Statistical  
>>> Software;
>>> US mail: 8125 Math Sciences Bldg, Box 951554, Los Angeles, CA  
>>> 90095-1554
>>> phone (310)-825-9550;  fax (310)-206-5658;  email: deleeuw at stat.ucla.edu
>>> .mac: jdeleeuw ++++++  aim: deleeuwjan ++++++ skype: j_deleeuw
>>> homepages: http://gifi.stat.ucla.edu ++++++ http://www.cuddyvalley.org
>>> -------------------------------------------------------------------------------------------------
>>>         No matter where you go, there you are. --- Buckaroo Banzai
>>>                  http://gifi.stat.ucla.edu/sounds/nomatter.au
>>> -------------------------------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -- 
>> Vincent Carey, PhD
>> Biostatistics, Channing Lab
>> 617 525 2265
>>
>> _______________________________________________
>> 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