[pkg-gnupg-maint] shipping libraries in debian for use when cross-building with mingw-w64-i686-dev (for win32-loader)

[Daniel Kahn Gillmor]

Hi Stephen--

Thanks for the prompt response!

On Mon 2016-02-15 07:26:14 -0500, Stephen Kitt wrote:
> This is where header files and DLLs should go; the compiler and linker 
> look there by default (/usr/{i686,x86_64}-w64-mingw32/{include,lib}).
>
> The overrides mention "For now" because the long-term plan is to add the 
> MinGW-w64 targets as Debian (partial) architectures 
> (https://bugs.debian.org/606825). Then the appropriate directories would 
> be /usr/{include,lib}/{i686,x86_64}-w64-mingw32 as per multi-arch...

Thanks for the explanation.  I've subscribed to that bug report (though
i confess i don't understand all the details discussed there) and i'm
happy to help make the per-package transitions necessary whenever the
shift to "true multiarch" happens.  Feel free to open bug reports
against any of the packages needed to be touched when that happens.

> Option 0 for header files and libraries, option 1 for executables. It 
> should be documented but isn't yet...

Ok, works for me.  The one possible exception, i think, will be the
${FOO}-config executable POSIX shell scripts, like gpg-error-config.
These will likely need to be carried forward for as long as upstream
objects to pkg-config [0].  I'm inclined to ship them in e.g.,
/usr/i686-w64-mingw32/bin/gpg-error-config, so that rdeps can
./configure --with-libgpg-error-prefix=/usr/i686-w64-mingw32 for now.
Does this make sense?

[0] https://bugs.debian.org/643341
    http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028473.html

> Sounds good; I should really write up a Windows policy of some sort.

Please do write one up, even if only a wiki page at the moment.  I'd be
happy to read it and give feedback.

> Please use lib...-mingw-w64 and lib...-mingw-w64-dev packages if 
> possible; see libz-mingw-w64 for an example (although that particular 
> package is rather inefficient since it's a new source package rather 
> than extra binary packages produced by zlib1g).

hm, I'm not convinced i want to introduce two new arch-independent
packages in each of these dependencies; it seems excessive when most of
these are just going to be used as build-dependencies.  I'm currently
thinking of making them strictly lib...-mingw-w64-dev, and leaving the
.dlls in that package.

Is there a practical reason to split out the .dlls separately from the
.dll.a's for debian systems?

Thanks for pointing out the libz-mingw-w64, also.  My attempted builds
have thus far only targeted i686-w64-mingw32.  I note that
libz-mingw-w64 additionally targets x86_684-w64-mingw32.  I'm inclined
to keep my current work focused just on the i686-w64-mingw32, but if you
have a good argument for why you'd want them both, please let me know.

> I'm thinking that upstream might be interested in this too, since having 
> those particular DLLs available as native Debian packages would be 
> helpful for building GnuPG Windows binaries in general!

Yep, agreed.  The current upstream approach to building GnuPG for
windows is a bit scary.  Hopefully this will make it easier for future
versions, and will make it easier for other people to hack on GnuPG for
Windows too.

Regards,

    --dkg