On Jul 25, 2009, at 7:32 PM, 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
My point was not that you should be using the binary, but rather that
you must have some issue in your setup since the nightly 64-bit builds
compile cleanly without any problems.
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?
No, any Xcode 3.x will do. The problem is in your 3rd party stuff
(apparently readline as you found yourself - and I don't know why you
had issues with system iconv which works for me...)
On Jul 25, 2009, at 8:56 PM, Vincent Carey wrote:
what must be done to get the i386- prefix corrected?
That is just cosmetics - you can change that with something like --
build=x86_64-apple-darwin`uname -r` but it has no practical effect.
Cheers,
S
looks like something much earlier is adequate at your place.
thanks
On Sat, Jul 25, 2009 at 6:06 PM, Simon
Urbanek<[email protected]> 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<[email protected]> 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<[email protected]> 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
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Vincent Carey, PhD
Biostatistics, Channing Lab
617 525 2265
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
