Request for discussion: Using PE libraries for Wine dependencies

[Zebediah Figura]

So, I figure it's probably worth quantifying what we'd gain this way (as 
well as how many libraries we'd potentially have to build or maintain). 
As I see it, the libraries that can be built as PE (unless I 
misunderstand what any one of them requires, so please correct me if I'm 
wrong) are:

* zlib (of course, we'd undo the source import)
* GLU
* OSMesa
* libxml2/libxslt
* gnutls
* v4l2 (but see below under qcap)
* freetype
* libunwind (but ntdll needs a .so component anyway)
* FAudio
* libgsm
* libkrb5/libgssapi
* jpeg, tiff, png
* mpg123
* openal?
* odbc?
* vkd3d

And libraries that cannot (or should not be) are:

* X11 (etc.)
* GL
* pcap (we could build this as PE, but then we'd need to implement 
things like ndis.sys, which would be painful.)
* dbus
* hal
* ncurses (I think?)
* sane
* gphoto2
* resolv (I think?)
* pulse
* gstreamer (we could build this as PE, but we'd lose host plugins)
* udev
* SDL2
* capi20
* cups
* netapi (or could we manhandle this into building on top of winsock?)
* vulkan

Which allows us to build the following as PE:

* wininet, dbghelp, opcservices, cabinet (already PE, but we could 
remove the imported zlib source)
* glu32 (but why do we have this again?)
* msxml3
* qcap? (It needs to do ioctls to Unix devices. But we can already open 
them with Win32 devices, and we could maybe map NtDeviceIoControlFile() 
to ioctl()?)
* dwrite
* xaudio et al.
* msgsm32.acm
* kerberos
* user32, windowscodecs
* mp3dmod
* openal32
* odbc32, odbccu32
* d3d12, dxgi

There's also the following, which we *could* build as PE if we throw 
away the Mac parts and require PE libraries—I don't think I can judge 
the impact of this:

* gdi32
* bcrypt, crypt32, secur32
* l3codeca.acm

On 2/14/20 12:43 PM, Esme Povirk (they/them) wrote:
> Options for distributing dependencies:
>   * Distribute headers and libs in a tarball built from wine-pedeps.
> The binaries would be part of an addon, also built from wine-pedeps.

I personally don't like this. I think there's value in
(1) not requiring the user to install libraries they don't need (like, 
say, libkrb5),
(2) not prompting for every add-on (personally I feel that two is 
already too many),
(3) letting the distribution choose what to distribute by default.

>   * Rely on the host distribution to package mingw headers, libs, and
> binaries for the dependencies we need. The binaries would then be
> distributed with Wine. Fedora is the only distribution I'm aware of
> that has an extensive library of mingw packages. To make this easier
> on other distros, I could maintain wine-pedeps as an alternative
> source of headers, libraries, and binaries at build time. The trouble
> with this approach is that it's not clear how we can keep Wine's
> libraries independent from the application. 
> 

This was the idea that I proposed when the discussion came up 
internally. It strikes me as the architecturally "correct" thing to do. 
We're essentially building some of our files with a different host 
architecture, so just as we'd link separately to x86_64-pc-linux-gnu 
libraries and i686-pc-linux-gnu libraries, so too would we link 
separately to x86_64-w64-mingw32 libraries (as well as i686-w64-mingw32).

Thus we'd want to adjust configure to check for those libraries using 
*-w64-mingw32-pkg-config, define separate m4 macros to wrap 
AC_CHECK_LIB/AC_CHECK_HEADER/WINE_CHECK_SONAME in mingw tools, etc, but 
the task of actually providing those headers and libraries stays outside 
of Wine.

That this is the right thing to do is, I think, proven by the fact that 
(some) distributions provide such libraries. [As Esme said, only Fedora 
provides all of the libraries we need, but I know that Debian/Ubuntu 
does provide zlib, although I think only zlib.] So of course it would be 
our responsibility to build and distribute those libraries for most 
distributions, until/unless we can merge them into their respective 
"main" repositories. I know Rosanne probably isn't thrilled about this, 
but I'd be willing to volunteer to maintain those packages.

I've attached a patch—very messy so far—that sort of outlines how this 
would work, converting msxml3 to PE. One thing it doesn't do but should 
is fall back to host tools when mingw isn't available. Generally, 
though, it should roughly illustrate what I'm trying to propose.

I don't know what we'd do about Mac, but along the same lines, I'd think 
we'd want to extend/analogize the current solution regarding bitness to 
the whole architecture triple.

> Perhaps an automated
> process could rename the binaries and edit their import tables, or sxs
> could be added after the fact.

I think some sort of manifest hack would be appropriate here, that ntdll 
would check when loading a builtin DLL. Presumably we don't even want 
the libraries to be copied into the prefix, but rather we want to make 
sure we load them always from /usr/i686-w64-mingw32/lib/* (or whatever 
the path is for any given distribution).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-awful-wip-msxml3-Build-with-msvcrt.patch
Type: text/x-patch
Size: 65149 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200412/7e914294/attachment-0001.bin>