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

[Stephen Kitt]

Hi Daniel,

On Mon, 15 Feb 2016 15:21:52 -0500, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> 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.

Will do! Don't hold your breath though ;-).

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

Ah, -config scripts, oh joy... ${prefix}/bin does make sense for now. I'm
planning on adding a pre-baked configure launcher, which could add that to
the PATH to make things simpler; or perhaps even a dh helper (I need to think
about that a bit more though).

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

Thanks for the offer, I'll let you know once I've done it (soon!).

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

Only requests such as
https://bugs.launchpad.net/ubuntu/+source/gcc-mingw-w64/+bug/1235983 which
doesn't matter quite as much for gpg libraries; I imagine the resulting
packages are small, and in any case from Debian's point of view the packages'
only purpose is building software, not running it. So feel free to ignore my
request!

> 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 just think it's a good idea to support 64-bit variants of Windows too.
It is now possible to configure some versions of Windows Server to only
support 64-bit executables, but I'm not sure how popular that is and I can't
imagine that affecting people wanting to use the executables we build for
Debian...

Regards,

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160220/6318b11c/attachment.sig>