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
