This is the mail archive of the
mailing list for the Cygwin project.
Re: Bug in libiconv?
- From: simrw at sim-basis dot de
- To: cygwin at cygwin dot com
- Date: Thu, 27 Jan 2011 13:16:51 +0100 (CET)
- Subject: Re: Bug in libiconv?
> If that doesn't correct the issue...then I'd try to run your test case
> on linux, but *explicitly* using libiconv on that system, rather than
> (as is typically the case on linux) relying on the underlying glibc
> implementation of iconv functionality.
> Did this. Here are the characteristics of the test case object and
> $ ldd ./foo
> linux-vdso.so.1 => (0x00007fff51928000)
> libiconv.so.2 => /home/me/libiconv/_inst/lib/libiconv.so.2
> libc.so.6 => /lib64/libc.so.6 (0x0000003d5b400000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003d5b000000)
> $ nm foo.o | grep ' U '
> U __errno_location
> U exit
> U fprintf
> >> U iconv
> >> U iconv_close
> >> U iconv_open
> U printf
> U setlocale
> U stderr
> U strerror
> U strlen
IMHO, that is not correctly compiled. You are still using
the version in glibc.
libiconv only has "libiconv_open", "libiconv_close" and "libiconv".
Looks like there is missing include path.
gcc -I/home/me/libiconv/_inst/include -o foo foo.c
iconv.h in libiconv has eg.
#define iconv_open libiconv_open
The "nm" should look like this -
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple