finding libiconv during static builds for windows

Daniel Kahn Gillmor dkg at
Tue Feb 16 10:40:39 CET 2016

When trying to build statically-linked executables for Windows, the
./configure script appears to prefer to find libiconv.dll.a instead of

checking if the linker (/usr/bin/i686-w64-mingw32-ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for working iconv... guessing yes
checking how to link with libiconv... /usr/i686-w64-mingw32/lib/libiconv.dll.a -L/usr/i686-w64-mingw32/lib
checking for iconv declaration... 
         extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
configure: checking for gettext

the result of this is that a statically-linked executable isn't fully
statically-linked -- it still needs iconv.dll to be shipped alongside

i'm supplying ./configure --with-libiconv-prefix=/usr/i686-w64-mingw32
as expected, and /usr/i686-w64-mingw32/lib/libiconv.a is definitely
present in the filesystem when ./configure is run.

i'm not sure how to convince ./configure that the correct flags are
-liconv -L/usr/i686-w64-mingw32/lib instead of the explicit path to the
libiconv.dll.a file.  Any pointers to the right place for this sort of


PS i'm doing this build with win-iconv, fwiw.  I haven't tried it with
GNU iconv.

More information about the Gnupg-devel mailing list