[Rd] Unable to build with working iconv support on Solaris9/x86
lucasjb at csse.unimelb.edu.au
Tue Jul 17 09:28:49 CEST 2007
Thanks for the advice, but I'm still confused!
On 17/07/2007, at 4:04 PM, Professor Brian Ripley wrote:
> Note that as the R-admin says, you need to use a better iconv than
> that supplied with most commercial Unices, including Solaris.
Yes, I read that and installed libiconv-1.11 locally before trying to
> - as a preload plugin
> - by installing it with the libiconv prefix, and ensuring its iconv.h
> is first in your path.
I've read a number of articles explaining why LD_PRELOAD is
considered harmful and should be avoided. I'm trying to be a good
systems administrator and do things the "right" way. As I understand
it RPATH (-R/somelocation argument to the linker) should take care of
this problem (but clearly it doesn't in this case).
When you say libiconv prefix, you're referring to '--with-libiconv-
prefix=/somelocation' correct? And what do you mean by "ensuring
iconv.h is first in your path"? If I provide CFLAGS="-I/
somelocation" that should be searched first for headers before the
default system locations as I understand? But surely once the binary
is built, the headers order doesn't matter?
> If you have two libraries with the same entry point (iconv here)
> which one gets resolved to is pretty arcane. Hence the need for
> a prefix.
Doesn't the output of 'ldd -s bin/exec/R' show the order in which
locations are searched for DSOs and confirm that /usr/local/apps/
libiconv-1.11/lib/libiconv.so.2 is found first and used?
You are correct though, 'LD_PRELOAD=/usr/local/apps/libiconv-1.11/lib/
libiconv.so make check' passes all tests up to d-p-q-r, whereas it
would usually fail on the first.
Lucas Barbuto E: lucasjb at csse.unimelb.edu.au
System Administrator T: +613 8344 1270
Department of CSSE
The University of Melbourne http://www.csse.unimelb.edu.au/
More information about the R-devel