Request for discussion: Using PE libraries for Wine dependencies

[Rémi Bernon]

On 4/13/20 1:18 AM, Zebediah Figura wrote:
> 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
> 
I believe SDL2 is special, it's used in two different places, for two 
different purposes. The one used from FAudio as a platform abstraction 
for audio backend should be built as PE when FAudio is, making it output 
sound to Wine audio DLLs instead of directly to the host.

The one used elsewhere for joystick abstraction is a host abstraction 
layer and should not.
-- 
Rémi Bernon <rbernon at codeweavers.com>