building gpgv 2.1 statically for win32 -- finding wrong iconv

Daniel Kahn Gillmor dkg at fifthhorseman.net
Tue Mar 29 17:54:25 CEST 2016


I'm trying to build gpgv 2.1 statically for the windows platform from a
debian system.  I want it to be static because i'd like to distribute it
in the debian installer's win32-loader, and i don't want to have to ship
extra .dll files with the .exe.

Instead of using full gcc libiconv (which isn't packaged separately from
libc on debian), i'm using the lighter-weight win-iconv.  debian's
win-iconv-mingw-w64-dev ships these files:

/usr/i686-w64-mingw32/lib/libiconv.dll.a
/usr/i686-w64-mingw32/lib/libiconv.a
/usr/i686-w64-mingw32/bin/iconv.dll
/usr/i686-w64-mingw32/include/iconv.h

The problem i'm having is that the configure process decides that the
LDFLAGS for libiconv are:

 -L/usr/i686-w64-mingw32/lib /usr/i686-w64-mingw32/lib/libiconv.dll.a

If i build like this, then the supposedly "statically-built" gpgv2.exe
that gets created still needs to find a copy of libiconv.dll.

If i replace the above with:

 -L/usr/i686-w64-mingw32/lib -liconv

then gpgv2.exe is correctly statically built.

How do i get ./configure to choose the latter approach instead of the
former?

I'm having a hard time wading through the ./configure scripts generated
by autoconf + m4/iconv.m4 to figure out what needs to change, but it
looks to me like the fact that $acl_library_names_spec is
'$libname.dll.a $libname.lib' is what's causing autoconf to select the
.dll.a instead of just using -liconv, but i don't know how that's set,
or how to override it.

any suggestions?

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160329/26789dce/attachment.sig>


More information about the Gnupg-devel mailing list