Hi Brian, 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 build R. > - 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. Regards, -- Lucas Barbuto E: [EMAIL PROTECTED] System Administrator T: +613 8344 1270 Department of CSSE The University of Melbourne http://www.csse.unimelb.edu.au/ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
