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

[Stephen Kitt]

Hi Daniel,

Le 14/02/2016 17:40, Daniel Kahn Gillmor a écrit :
> I'm trying to sort out the cross-building toolchain in debian for 
> making
> windows binaries, for the sake of making things that will contribute to
> win32-loader.
> 
> My main question is: when shipping cross-built libraries (.dll, .dll.a,
> .la, and .a files) and header files for use on debian by other
> cross-builders targetting win32, where do you think those libraries
> should be placed in the filesystem?  I see two options:
> 
>  0) /usr/i686-w64-mingw32
> 
> This is where a bunch of dll's and header files already shipped by
> mingw-w64-i686-dev live.
> 
> /usr/share/lintian/overrides/mingw-w64-i686-dev says in part:
> 
>> # For now files are in /usr/${target}
>> mingw-w64-i686-dev: file-in-unusual-dir
>> mingw-w64-i686-dev: non-standard-dir-in-usr
> 
> I'm not sure what the "For now" is about.  is there a larger plan?

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...

>  1) /usr/share/win32
> 
> This is currently where the files that target win32-loader live, like
> gzip-win32 and cpio-win32.  It's possible that this is only desirable
> for the final .exe files produced for win32-loader, and that it should
> not be used for the "intermediate" products like win32 libraries.

Exactly, that's the historical directory for executables used by 
win32-loader, and I kept it for final executables because /usr/bin 
doesn't seem particularly appropriate. (As long as the MinGW-w64 targets 
aren't multi-arch compliant anyway.)

> Do you have a preference?  Do you see other options?  Is any of this
> documented somewhere i should read up on?

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

> Background: i'm currently working on updating gpgv-win32 to build it
> From the "modern" GnuPG suite (2.1.x) instead of the "classic" suite
> (1.4.x).  Unlike the classic suite, the modern suite depends on a small
> number of libraries that themselves need to be cross-built and 
> available
> before gpgv.exe can be linked.  I plan to build gpgv.exe statically so
> that win32-loader doesn't have to deal with any dll's explicitly, but 
> to
> do that i want to make sure that we have the underlying libraries
> packaged and available properly.
> 
> At the minimum, this will include win32 builds for:
> 
>  * libgpg-error
>  * libgcrypt
> 
> And it might be simplest for the overall process of producing gpgv.exe
> From 2.1.x to produce win32 builds for (even though gpgv itself doesn't
> depend on them):
> 
>  * libassuan
>  * libksba
> 
> I'm preparing all the source changes needed for these -- i'll file bugs
> with patches for the ones handled by Andreas, but i want to be sure 
> that
> i'm putting things in the right place.

Sounds good; I should really write up a Windows policy of some sort. 
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).

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!

Regards,

Stephen