[Rd] Unable to build with working iconv support on Solaris9/x86

[Lucas Barbuto]

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: 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/