The current iconv testing done within the autoconf script is broken on OS's that use gettext and fails to detect the presence of iconv. The problem is that the snippet of code generated by autoconf to detect the presence of iconv does not include the iconv.h header which is required. Using the autoconf macro from gettext itself would resolve this issue.
The current iconv testing done within the autoconf script is broken on OS's that use gettext and fails to detect the presence of iconv. The problem is that the snippet of code generated by autoconf to detect the presence of iconv does not include the iconv.h header which is _required_. Using the autoconf macro from gettext itself would resolve this issue.
<!-- github-sync-id:8439109 -->
It is not "my" iconv.h. It is gettext. The header does define the symbol to another name if gettext is used on an OS where its a standalone library (libintl) instead of a plugin to libc (GLIBC).
It is not "my" iconv.h. It is gettext. The header does define the symbol to another name if gettext is used on an OS where its a standalone library (libintl) instead of a plugin to libc (GLIBC).
<!-- github-comment-id:10472447 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The current iconv testing done within the autoconf script is broken on OS's that use gettext and fails to detect the presence of iconv. The problem is that the snippet of code generated by autoconf to detect the presence of iconv does not include the iconv.h header which is required. Using the autoconf macro from gettext itself would resolve this issue.
Uhm, what magic does your iconv.h do? Does it #define iconv to something else or what?
It is not "my" iconv.h. It is gettext. The header does define the symbol to another name if gettext is used on an OS where its a standalone library (libintl) instead of a plugin to libc (GLIBC).
May you give us the fix, since you already looked at the issue anyway?