This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.0 RC2 Available


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]