On Tue, Apr 19, 2005 at 04:20:19PM +0000, Joseph S. Myers wrote: > On Mon, 18 Apr 2005, Joe Buck wrote: > > > It appears the bug is because there's a libiconv.so in /usr/local/lib on > > that machine, with headers in /usr/local/include, but /usr/local/lib isn't > > in my LD_LIBRARY_PATH. configure finds the declaration and assumes it > > can call the function. Sorry, I do most of my work in GNU/Linux these > > days so my Solaris setup has rotted. I'll try that one again with a > > proper LD_LIBRARY_PATH. > > The iconv bugs are 7881, 10657, 12596, 18303. I think the documentation > will need to have soemthing added about LD_LIBRARY_PATH for libiconv, > while 18303 is the one to fix first in order to get the configuration > right; it may be necessary to determine whether the header is system > iconv.h or from GNU libiconv, and likewise for the library (-liconv ought > to be GNU libiconv while no special library means using libc) and take > care to avoid getting GNU iconv.h but libc iconv or GNU libiconv but libc > iconv.h (the include and linker search paths used in configuration may not > be consistent if --with-libiconv-prefix hasn't been used).
In my case, the /usr/local copy was GNU libiconv. --with-libiconv-prefix was needed to make things work. I think that autoconf, fiding an iconv in one of the "standard locations" (/usr/include, /usr/local/include) assumed that it had determined that there was an iconv in the standard library.
