Re: shipping libraries in debian for use when cross-building with mingw-w64-i686-dev (for win32-loader)
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
Reply to: