The idea of using PE libraries for some Wine library dependencies came up recently because of a bug in CrossOver's 32-bit support on Mac (which uses 64-bit system libraries). Wine's xaudio libraries don't do any translation of 32-bit structures to 64-bit for the native FAudio, meaning that in this configuration, they don't work at all. If FAudio and xaudio were both built as a PE, 32-bit binary, we wouldn't need this translation.
Not all dependencies could be used in PE form, anything that needs to interact with the host system wouldn't work. We'll always need native libraries for X11, OpenGL, Vulkan, and host audio libraries, for example. Only libraries like libpng or FAudio which can function based on win32 API's we provide (and/or other libraries) could work.
Advantages: * This reduces the surface area of Wine's interface between the virtual Windows environment and host libraries. That makes the transition to PE simpler, and should make it easier to implement 32-bit with 64-bit host libraries in the official Wine release (because fewer thunks to 64-bit host libraries will be required). * It reduces dependencies on host libraries. If FAudio.dll is shipped with Wine or in some other way, users won't need an FAudio package from the host distribution. * It allows code sharing between Wine itself and the Mono and Gecko addons. It's kinda silly that Wine already ships an FAudio.dll, inside Wine Mono, for its XNA support. Wine's xaudio could theoretically be sharing this code, but it isn't.
Requirements: * Any solution should function even if mingw is not available in the build environment. This is a challenge because the headers may not work correctly in the winelib build environment. In particular, the calling convention is different between 64-bit Windows and everywhere else, which requires us to decorate Gecko and Mono exports with CDECL so we can call them correctly. It may be possible to work around this problem by wrapping the headers with pragma GCC target. * We probably shouldn't break anything that works in any currently supported ports. With llvm-mingw, we now have the ability to build PE libraries for arm and aarch64 (I've built SDL2 and FAudio this way myself, but I don't have a test environment for them). I'm not sure of the status of the PowerPC and sparc ports. Are these maintained? Do we care? If we do, we'll need to preserve the ability to use native libraries, or build the libraries in winelib. * Our versions of PE dependency libraries must be independent of an application shipping the same libraries. If we ship an FAudio.dll, and an application ships an incompatible FAudio.dll, Wine and the application should each load their own version. This is not an unlikely scenario, as many libraries make use of C standard library features such as FILE or malloc/free in their API's, which means that the ABI depends on which version of the Microsoft C runtime was used to compile it.
I started a proof of concept, but I got stuck on the question of how to distribute the FAudio headers, link-time libraries, and binaries.
Part of my proof of concept is a repo on github: https://github.com/madewokherd/wine-pedeps
Currently, that project builds a couple of PE libraries and does nothing else. It could be developed further to generate packages of headers, libraries, and/or binaries. I'll be referring to that project as wine-pedeps.
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. * Import the headers into the Wine tree, and link using LoadLibrary so we don't need .lib files. The headers could be an output from wine-pedeps that gets dropped into a folder like include/wine/external. For building Gecko and Mono, we'd still get headers and libs from wine-pedeps. No one seems to like this idea. * Depend on headers from the host distribution for the corresponding Linux library, and link using LoadLibrary. I'm not sure if this can work reliably, or even if we can make host headers accessible inside mingw without breaking things. For building Gecko and Mono, we'd still get headers and libs from wine-pedeps. * Import entire projects into the Wine tree, perhaps as a submodule. We would then build them and distribute them with Wine. In case mingw is not available, we'd need the option of building them with winelib, or using a host library instead. I don't think the Wine maintainer likes submodules, and I personally don't like the idea of bloating the Wine source distribution the way Mono's use of this approach has forced bloat on the Wine Mono source tree. * 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. Perhaps an automated process could rename the binaries and edit their import tables, or sxs could be added after the fact.
Hi Vincent,
Thanks for bringing it up. I gave it some thoughts and below is how I envision this could be done.
Wine has very nice and pure build system. I think that's something definitely worth preserving, but at the same time keep building fully functional Wine package simple. What we'd need is a separate repository which would make building dependencies easy and optionally handle building even core Wine. We would provide MSI-based downloadable installers like we do for other addons as a fallback, but intended use would involve shipping Wine with addons. I'd think about those repos as Wine core (the platform including both runtime Windows implementation and SDK to build for it) and a separate new "wine-dist" repo (a tool to build that manages building Wine distribution). As such, Wine itself would be independent like it is now, but at the same time could be optionally managed by the new build system.
Wine would need to be aware of addons header location. It would look for some standard places and have a configure option to specify a custom one. makedep would be aware of that. We would use only headers, no binaries. This way a downloadable, headers-only package would be enough to build core Wine from sources (although it's still not perfect, better ideas welcomed).
Wine addons would be marked as builtin and installed in standard Wine location (we may need to revisit what that standard location is). MSI files would install files to system32. Then loading them would be as easy as LoadLibraryW(L"wine-faudio-1.dll") or similar. We'd probably want a helper that would optionally invoke addon installer in case of failure.
winegcc and other Wine tools could be used as a powerful cross platform tool for building targeting Wine. We could use that for addons builds. The main supported way of building addons would be with mingw-backed winegcc that that's what we'd ship. winegcc provides, in theory, an easy way to build things as ELF winelib files. So if someone shows up trying to build that for powerpc, tools would be in place and patches welcomed. In theory it could be a matter of using the right configure options. In practice, it would probably require quite a bit of tweaking.
Of course, building with winegcc is probably an extra complications and would need a serious Wine work first. mingw-backed winegcc is not quite ready to stabilize on, IMHO, but it's getting there and it would be interesting to experiment with it. I'm happy to help. If we could get things to work in "-mno-cygwin" mode, we could provide a stable and portable build environment. Building autoconf-based subprojects would be handled by our makefiles (similar to how you did it) and probably look like:
.../configure CC="$WINEGCC -b $target" --host=$arch-w64-mingw32
Now back to the repo that would handle addons. I imagine that it would make distributing fully functional Wine with simple ./configure && make && make install. For that, it would do basic checks and handle multiple submodules. It will build winelib part of Wine, use that for building addons and build Wine runtime itself against fresh addons headers. It could even handle win32+win64 builds in a bit more friendly way than we do now.
All of that would be optional. If someone prefers to build Wine itself the usual way, there would be ./configure --with-system-wine or ./configure --with-wine-objdir=... etc. Similar for other libraries: ./configure --with-faudio-srcdir=... if someone prefers an alternative faudio version. It should be easy to make it very flexible and easy to use.
Optionally, I can even imagine bootstrapping cross toolchain as a part of the build. It's not too hard to build LLVM or GCC+binutils. I imagine that distros would better ship it themselves, but we could have an optional bootstrapping for a reference platform.
An important consideration is versioning and API stability. Of course, in this case, we don't control API of projects that we import, so we can't make a promise of API stability. Runtime detection seems easy: we need to rename module and mark it builtin, we may as well add ABI version to the name and increment it whenever ABI version of the library changes. Wine builds would try to load only the ABI version they are built against. What versions of headers do we allow as Wine to be built against is another question. Limiting that 1:1 mapping it tempting because of simplicity and avoiding #ifdefing.
Examples of the theoretical new repo use:
To build a complete Wine win32+win64 Wine package with additional addons and install the whole thing as a single:
./configure && make && make install
To build Wine addons using previously installed Wine (the standard way or with help if the new tool):
./configure --with-system-wine && make && make install
To build Wine addons, but use alternative SDL2 sources, without faudio:
./configure --with-faudio-sdl2dir=... --without-faudio && make && make install
To build complete Wine with PE files and functional cross compiler on a distro that doesn't provide required tools:
./configure --enable-bootstrap-llvm
To have separated build dirs for Wine and addons (probably useful for developers doing multiple builds, I'd expect to use it):
.../configure --with-wine-objdir=path/to/main/objdir && make # builds Wine addons using tools from specified Wine builds
And in Wine tree:
.../configure --with-wine-addons-dir=...
So that what I came up with. It aligns with Vincent's thoughts in many places. And I'm sure there are other good solutions as well. Comments and ideas welcomed.
Cheers,
Jacek
On 2/14/20 7:43 PM, Vincent Povirk (they/them) wrote:
The idea of using PE libraries for some Wine library dependencies came up recently because of a bug in CrossOver's 32-bit support on Mac (which uses 64-bit system libraries). Wine's xaudio libraries don't do any translation of 32-bit structures to 64-bit for the native FAudio, meaning that in this configuration, they don't work at all. If FAudio and xaudio were both built as a PE, 32-bit binary, we wouldn't need this translation.
Not all dependencies could be used in PE form, anything that needs to interact with the host system wouldn't work. We'll always need native libraries for X11, OpenGL, Vulkan, and host audio libraries, for example. Only libraries like libpng or FAudio which can function based on win32 API's we provide (and/or other libraries) could work.
Advantages:
- This reduces the surface area of Wine's interface between the
virtual Windows environment and host libraries. That makes the transition to PE simpler, and should make it easier to implement 32-bit with 64-bit host libraries in the official Wine release (because fewer thunks to 64-bit host libraries will be required).
- It reduces dependencies on host libraries. If FAudio.dll is shipped
with Wine or in some other way, users won't need an FAudio package from the host distribution.
- It allows code sharing between Wine itself and the Mono and Gecko
addons. It's kinda silly that Wine already ships an FAudio.dll, inside Wine Mono, for its XNA support. Wine's xaudio could theoretically be sharing this code, but it isn't.
Requirements:
- Any solution should function even if mingw is not available in the
build environment. This is a challenge because the headers may not work correctly in the winelib build environment. In particular, the calling convention is different between 64-bit Windows and everywhere else, which requires us to decorate Gecko and Mono exports with CDECL so we can call them correctly. It may be possible to work around this problem by wrapping the headers with pragma GCC target.
- We probably shouldn't break anything that works in any currently
supported ports. With llvm-mingw, we now have the ability to build PE libraries for arm and aarch64 (I've built SDL2 and FAudio this way myself, but I don't have a test environment for them). I'm not sure of the status of the PowerPC and sparc ports. Are these maintained? Do we care? If we do, we'll need to preserve the ability to use native libraries, or build the libraries in winelib.
- Our versions of PE dependency libraries must be independent of an
application shipping the same libraries. If we ship an FAudio.dll, and an application ships an incompatible FAudio.dll, Wine and the application should each load their own version. This is not an unlikely scenario, as many libraries make use of C standard library features such as FILE or malloc/free in their API's, which means that the ABI depends on which version of the Microsoft C runtime was used to compile it.
I started a proof of concept, but I got stuck on the question of how to distribute the FAudio headers, link-time libraries, and binaries.
Part of my proof of concept is a repo on github: https://github.com/madewokherd/wine-pedeps
Currently, that project builds a couple of PE libraries and does nothing else. It could be developed further to generate packages of headers, libraries, and/or binaries. I'll be referring to that project as wine-pedeps.
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.
- Import the headers into the Wine tree, and link using LoadLibrary
so we don't need .lib files. The headers could be an output from wine-pedeps that gets dropped into a folder like include/wine/external. For building Gecko and Mono, we'd still get headers and libs from wine-pedeps. No one seems to like this idea.
- Depend on headers from the host distribution for the corresponding
Linux library, and link using LoadLibrary. I'm not sure if this can work reliably, or even if we can make host headers accessible inside mingw without breaking things. For building Gecko and Mono, we'd still get headers and libs from wine-pedeps.
- Import entire projects into the Wine tree, perhaps as a submodule.
We would then build them and distribute them with Wine. In case mingw is not available, we'd need the option of building them with winelib, or using a host library instead. I don't think the Wine maintainer likes submodules, and I personally don't like the idea of bloating the Wine source distribution the way Mono's use of this approach has forced bloat on the Wine Mono source tree.
- 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. Perhaps an automated process could rename the binaries and edit their import tables, or sxs could be added after the fact.
What about extending a bit the Wine build system to support external sources? Then you could configure Wine with:
configure --with-sdl2-src=... --with-faudio-src=...
And that would build wine-specific PE wrappers from the sources of the projects, and use the headers from there when building the dependent DLLs.
If the sources aren't provided, then fallback to the current implementation with system dependencies and ELF builtins instead.
That way we won't have much pollution in Wine's tree, we just need an annoying list of sources, a spec file, and maybe a custom config like for SDL2. It also makes it easier for anyone to customize the dependencies without having to go through a separate build process.
I'm attaching a PoC implementation to illustrate, it's not super clean and there's a lot of build warnings but it appears to be working. And the xaudio family libraries can then be built as PE.
Now I'm not completely sure how symbol resolution works on Windows, but if my understanding is correct there should be no conflicts -or we'd also have to rename all the exported functions.
Cheers,
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=69393
Your paranoid android.
=== debiant (build log) ===
/usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x28): undefined reference to `F3DAudioCalculate' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x2c): undefined reference to `F3DAudioInitialize' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x30): undefined reference to `F3DAudioInitialize8' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x34): undefined reference to `FAPOFX_CreateFXWithCustomAllocatorEXT' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x38): undefined reference to `FAudioMasteringVoice_GetChannelMask' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x3c): undefined reference to `FAudioSourceVoice_GetFrequencyRatio' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x40): undefined reference to `FAudioSourceVoice_SetSourceSampleRate' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x44): undefined reference to `FAudioVoice_DisableEffect' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x48): undefined reference to `FAudioVoice_EnableEffect' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x4c): undefined reference to `FAudioVoice_GetChannelVolumes' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x50): undefined reference to `FAudioVoice_GetEffectParameters' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x54): undefined reference to `FAudioVoice_GetEffectState' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x58): undefined reference to `FAudioVoice_GetFilterParameters' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x5c): undefined reference to `FAudioVoice_GetOutputFilterParameters' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x60): undefined reference to `FAudioVoice_GetOutputMatrix' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x64): undefined reference to `FAudioVoice_GetVoiceDetails' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x68): undefined reference to `FAudioVoice_GetVolume' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x6c): undefined reference to `FAudioVoice_SetChannelVolumes' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x70): undefined reference to `FAudioVoice_SetEffectChain' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x74): undefined reference to `FAudioVoice_SetEffectParameters' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x78): undefined reference to `FAudioVoice_SetFilterParameters' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x7c): undefined reference to `FAudioVoice_SetOutputFilterParameters' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x80): undefined reference to `FAudioVoice_SetOutputMatrix' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x84): undefined reference to `FAudioVoice_SetVolume' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x88): undefined reference to `FAudio_Initialize' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x8c): undefined reference to `FAudioCOMConstructWithCustomAllocatorEXT' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x90): undefined reference to `FAudioCreateReverbWithCustomAllocatorEXT' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x94): undefined reference to `FAudioCreateVolumeMeterWithCustomAllocatorEXT' -w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0x9c): undefined reference to `FAudioSourceVoice_Discontinuity' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xa0): undefined reference to `FAudioSourceVoice_ExitLoop' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xa4): undefined reference to `FAudioSourceVoice_FlushSourceBuffers' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xa8): undefined reference to `FAudioSourceVoice_GetState' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xac): undefined reference to `FAudioSourceVoice_SetFrequencyRatio' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xb0): undefined reference to `FAudioSourceVoice_Start' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xb4): undefined reference to `FAudioSourceVoice_Stop' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xb8): undefined reference to `FAudioSourceVoice_SubmitSourceBuffer' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xbc): undefined reference to `FAudioVoice_DestroyVoice' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xc0): undefined reference to `FAudioVoice_SetOutputVoices' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xc4): undefined reference to `FAudio_AddRef' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xc8): undefined reference to `FAudio_CommitOperationSet' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xcc): undefined reference to `FAudio_CreateMasteringVoice' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xd0): undefined reference to `FAudio_CreateMasteringVoice8' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xd4): undefined reference to `FAudio_CreateSourceVoice' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xd8): undefined reference to `FAudio_CreateSubmixVoice' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xdc): undefined reference to `FAudio_GetDeviceCount' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xe0): undefined reference to `FAudio_GetDeviceDetails' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xe4): undefined reference to `FAudio_GetPerformanceData' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xe8): undefined reference to `FAudio_RegisterForCallbacks' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xec): undefined reference to `FAudio_Release' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xf0): undefined reference to `FAudio_SetDebugConfiguration' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xf4): undefined reference to `FAudio_SetEngineProcedureEXT' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xf8): undefined reference to `FAudio_StartEngine' /usr/bin/i686-w64-mingw32-ld: wine-faudio.dll-kX1HyI.spec.o:fake:(.edata+0xfc): undefined reference to `FAudio_StopEngine' collect2: error: ld returned 1 exit status /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x28): undefined reference to `SDL_CloseAudioDevice' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x2c): undefined reference to `SDL_CreateMutex' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x30): undefined reference to `SDL_CreateThread' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x34): undefined reference to `SDL_Delay' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x38): undefined reference to `SDL_DestroyMutex' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x3c): undefined reference to `SDL_GetAudioDeviceName' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x40): undefined reference to `SDL_GetError' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x44): undefined reference to `SDL_GetNumAudioDevices' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x48): undefined reference to `SDL_GetTicks' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x4c): undefined reference to `SDL_HasNEON' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x50): undefined reference to `SDL_HasSSE2' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x54): undefined reference to `SDL_InitSubSystem' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x58): undefined reference to `SDL_LockMutex' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x5c): undefined reference to `SDL_Log' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x60): undefined reference to `SDL_OpenAudioDevice' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x64): undefined reference to `SDL_PauseAudioDevice' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x68): undefined reference to `SDL_QuitSubSystem' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x6c): undefined reference to `SDL_RWFromFile' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x70): undefined reference to `SDL_RWFromMem' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x74): undefined reference to `SDL_SetThreadPriority' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x78): undefined reference to `SDL_ThreadID' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x7c): undefined reference to `SDL_UnlockMutex' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x80): undefined reference to `SDL_WaitThread' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x84): undefined reference to `SDL_abs' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x88): undefined reference to `SDL_acosf' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x8c): undefined reference to `SDL_atan2f' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x90): undefined reference to `SDL_atoi' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x94): undefined reference to `SDL_ceil' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x98): undefined reference to `SDL_cos' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x9c): undefined reference to `SDL_cosf' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xa0): undefined reference to `SDL_exp' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xa4): undefined reference to `SDL_fabsf' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xa8): undefined reference to `SDL_floor' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xac): undefined reference to `SDL_free' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xb0): undefined reference to `SDL_getenv' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xb4): undefined reference to `SDL_log' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xb8): undefined reference to `SDL_log10' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xbc): undefined reference to `SDL_malloc' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xc0): undefined reference to `SDL_memcmp' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xc4): undefined reference to `SDL_memcpy' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xc8): undefined reference to `SDL_memset' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xcc): undefined reference to `SDL_pow' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xd0): undefined reference to `SDL_qsort' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xd4): undefined reference to `SDL_realloc' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xd8): undefined reference to `SDL_scalbn' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xdc): undefined reference to `SDL_sin' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xe0): undefined reference to `SDL_sinf' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xe4): undefined reference to `SDL_snprintf' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xe8): undefined reference to `SDL_sqrtf' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xec): undefined reference to `SDL_strcmp' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xf0): undefined reference to `SDL_strlcpy' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xf4): undefined reference to `SDL_strlen' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xf8): undefined reference to `SDL_strstr' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0xfc): undefined reference to `SDL_tan' /usr/bin/i686-w64-mingw32-ld: wine-sdl2.dll-C7AvbI.spec.o:fake:(.edata+0x100): undefined reference to `SDL_vsnprintf' collect2: error: ld returned 1 exit status Task: The win32 Wine build failed
=== debiant (build log) ===
/usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x28): undefined reference to `F3DAudioCalculate' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x2c): undefined reference to `F3DAudioInitialize' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x30): undefined reference to `F3DAudioInitialize8' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x34): undefined reference to `FAPOFX_CreateFXWithCustomAllocatorEXT' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x38): undefined reference to `FAudioMasteringVoice_GetChannelMask' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x3c): undefined reference to `FAudioSourceVoice_GetFrequencyRatio' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x40): undefined reference to `FAudioSourceVoice_SetSourceSampleRate' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x44): undefined reference to `FAudioVoice_DisableEffect' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x48): undefined reference to `FAudioVoice_EnableEffect' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x4c): undefined reference to `FAudioVoice_GetChannelVolumes' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x50): undefined reference to `FAudioVoice_GetEffectParameters' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x54): undefined reference to `FAudioVoice_GetEffectState' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x58): undefined reference to `FAudioVoice_GetFilterParameters' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x5c): undefined reference to `FAudioVoice_GetOutputFilterParameters' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x60): undefined reference to `FAudioVoice_GetOutputMatrix' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x64): undefined reference to `FAudioVoice_GetVoiceDetails' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x68): undefined reference to `FAudioVoice_GetVolume' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x6c): undefined reference to `FAudioVoice_SetChannelVolumes' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x70): undefined reference to `FAudioVoice_SetEffectChain' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x74): undefined reference to `FAudioVoice_SetEffectParameters' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x78): undefined reference to `FAudioVoice_SetFilterParameters' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x7c): undefined reference to `FAudioVoice_SetOutputFilterParameters' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x80): undefined reference to `FAudioVoice_SetOutputMatrix' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x84): undefined reference to `FAudioVoice_SetVolume' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x88): undefined reference to `FAudio_Initialize' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x8c): undefined reference to `FAudioCOMConstructWithCustomAllocatorEXT' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x90): undefined reference to `FAudioCreateReverbWithCustomAllocatorEXT' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x94): undefined reference to `FAudioCreateVolumeMeterWithCustomAllocatorEXT' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x98): undefined reference to `FAudioLinkedVersion' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0x9c): undefined reference to `FAudioSourceVoice_Discontinuity' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xa0): undefined reference to `FAudioSourceVoice_ExitLoop' +0xa4): undefined reference to `FAudioSourceVoice_FlushSourceBuffers' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xa8): undefined reference to `FAudioSourceVoice_GetState' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xac): undefined reference to `FAudioSourceVoice_SetFrequencyRatio' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xb0): undefined reference to `FAudioSourceVoice_Start' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xb4): undefined reference to `FAudioSourceVoice_Stop' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xb8): undefined reference to `FAudioSourceVoice_SubmitSourceBuffer' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xbc): undefined reference to `FAudioVoice_DestroyVoice' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xc0): undefined reference to `FAudioVoice_SetOutputVoices' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xc4): undefined reference to `FAudio_AddRef' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xc8): undefined reference to `FAudio_CommitOperationSet' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xcc): undefined reference to `FAudio_CreateMasteringVoice' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xd0): undefined reference to `FAudio_CreateMasteringVoice8' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xd4): undefined reference to `FAudio_CreateSourceVoice' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xd8): undefined reference to `FAudio_CreateSubmixVoice' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xdc): undefined reference to `FAudio_GetDeviceCount' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xe0): undefined reference to `FAudio_GetDeviceDetails' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xe4): undefined reference to `FAudio_GetPerformanceData' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xe8): undefined reference to `FAudio_RegisterForCallbacks' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xec): undefined reference to `FAudio_Release' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xf0): undefined reference to `FAudio_SetDebugConfiguration' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xf4): undefined reference to `FAudio_SetEngineProcedureEXT' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xf8): undefined reference to `FAudio_StartEngine' /usr/bin/x86_64-w64-mingw32-ld: wine-faudio.dll-GLeiPg.spec.o:fake:(.edata+0xfc): undefined reference to `FAudio_StopEngine' collect2: error: ld returned 1 exit status /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x28): undefined reference to `SDL_CloseAudioDevice' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x2c): undefined reference to `SDL_CreateMutex' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x30): undefined reference to `SDL_CreateThread' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x34): undefined reference to `SDL_Delay' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x38): undefined reference to `SDL_DestroyMutex' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x3c): undefined reference to `SDL_GetAudioDeviceName' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x40): undefined reference to `SDL_GetError' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x44): undefined reference to `SDL_GetNumAudioDevices' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x48): undefined reference to `SDL_GetTicks' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x4c): undefined reference to `SDL_HasNEON' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x50): undefined reference to `SDL_HasSSE2' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x54): undefined reference to `SDL_InitSubSystem' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x58): undefined reference to `SDL_LockMutex' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x5c): undefined reference to `SDL_Log' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x60): undefined reference to `SDL_OpenAudioDevice' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x64): undefined reference to `SDL_PauseAudioDevice' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x68): undefined reference to `SDL_QuitSubSystem' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x6c): undefined reference to `SDL_RWFromFile' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x70): undefined reference to `SDL_RWFromMem' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x74): undefined reference to `SDL_SetThreadPriority' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x78): undefined reference to `SDL_ThreadID' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x7c): undefined reference to `SDL_UnlockMutex' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x80): undefined reference to `SDL_WaitThread' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x84): undefined reference to `SDL_abs' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x88): undefined reference to `SDL_acosf' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x8c): undefined reference to `SDL_atan2f' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x90): undefined reference to `SDL_atoi' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x94): undefined reference to `SDL_ceil' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x98): undefined reference to `SDL_cos' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x9c): undefined reference to `SDL_cosf' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xa0): undefined reference to `SDL_exp' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xa4): undefined reference to `SDL_fabsf' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xa8): undefined reference to `SDL_floor' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xac): undefined reference to `SDL_free' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xb0): undefined reference to `SDL_getenv' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xb4): undefined reference to `SDL_log' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xb8): undefined reference to `SDL_log10' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xbc): undefined reference to `SDL_malloc' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xc0): undefined reference to `SDL_memcmp' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xc4): undefined reference to `SDL_memcpy' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xc8): undefined reference to `SDL_memset' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xcc): undefined reference to `SDL_pow' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xd0): undefined reference to `SDL_qsort' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xd4): undefined reference to `SDL_realloc' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xd8): undefined reference to `SDL_scalbn' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xdc): undefined reference to `SDL_sin' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xe0): undefined reference to `SDL_sinf' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xe4): undefined reference to `SDL_snprintf' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xe8): undefined reference to `SDL_sqrtf' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xec): undefined reference to `SDL_strcmp' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xf0): undefined reference to `SDL_strlcpy' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xf4): undefined reference to `SDL_strlen' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xf8): undefined reference to `SDL_strstr' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0xfc): undefined reference to `SDL_tan' /usr/bin/x86_64-w64-mingw32-ld: wine-sdl2.dll-v5PIof.spec.o:fake:(.edata+0x100): undefined reference to `SDL_vsnprintf' collect2: error: ld returned 1 exit status Task: The wow64 Wine build failed
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).
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=69413
Your paranoid android.
=== debiant (32 bit report) ===
msxml3: domdoc.c:111: Test failed: class DOMDocument, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument2, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument2, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument30, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument30, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument40, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument40, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument3 not supported domdoc.c:111: Test failed: class FreeThreadedDOMDocument, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class FreeThreadedDOMDocument, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class XMLSchemaCache, iface IXMLDOMSchemaCollection not supported domdoc.c:13029: Test failed: DOMDocument2 is not supported. Skipping all tests. httpreq.c:1905: Test failed: IXMLHTTPRequest is not available saxreader.c:5767: Test failed: Failed to create SAXXMLReader instance schema.c:511: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:669: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:670: Test failed: Failed to create a document. schema.c:672: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:673: Test failed: Failed to create schema collection. schema.c:789: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:790: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:791: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:793: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:884: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:885: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:886: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:888: Test failed: failed to create CLSID_XMLSchemaCache30 instance: 0x80004001 schema.c:889: Test failed: failed to create CLSID_XMLSchemaCache40 instance: 0x80004001 schema.c:1031: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1032: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1033: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1214: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1215: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1216: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1217: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1417: Test failed: failed to create CLSID_XMLSchemaCache40 instance: 0x80004001 schema.c:1494: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1536: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 schema.c:1569: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 schema.c:1658: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 xmldoc.c:518: Test failed: Failed to create XMLDocument instance xmlview.c:160: Test failed: Failed to create XMLView instance xmlview.c:220: Test failed: Failed to create XMLView instance
=== debiant (32 bit Chinese:China report) ===
msxml3: domdoc.c:111: Test failed: class DOMDocument, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument2, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument2, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument30, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument30, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument40, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument40, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument3 not supported domdoc.c:111: Test failed: class FreeThreadedDOMDocument, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class FreeThreadedDOMDocument, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class XMLSchemaCache, iface IXMLDOMSchemaCollection not supported domdoc.c:13029: Test failed: DOMDocument2 is not supported. Skipping all tests. httpreq.c:1905: Test failed: IXMLHTTPRequest is not available saxreader.c:5767: Test failed: Failed to create SAXXMLReader instance schema.c:511: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:669: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:670: Test failed: Failed to create a document. schema.c:672: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:673: Test failed: Failed to create schema collection. schema.c:789: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:790: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:791: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:793: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:884: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:885: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:886: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:888: Test failed: failed to create CLSID_XMLSchemaCache30 instance: 0x80004001 schema.c:889: Test failed: failed to create CLSID_XMLSchemaCache40 instance: 0x80004001 schema.c:1031: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1032: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1033: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1214: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1215: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1216: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1217: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1417: Test failed: failed to create CLSID_XMLSchemaCache40 instance: 0x80004001 schema.c:1494: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1536: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 schema.c:1569: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 schema.c:1658: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 xmldoc.c:518: Test failed: Failed to create XMLDocument instance xmlview.c:160: Test failed: Failed to create XMLView instance xmlview.c:220: Test failed: Failed to create XMLView instance
=== debiant (32 bit WoW report) ===
msxml3: domdoc.c:111: Test failed: class DOMDocument, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument2, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument2, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument30, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument30, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument40, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument40, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument3 not supported domdoc.c:111: Test failed: class FreeThreadedDOMDocument, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class FreeThreadedDOMDocument, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class XMLSchemaCache, iface IXMLDOMSchemaCollection not supported domdoc.c:13029: Test failed: DOMDocument2 is not supported. Skipping all tests. httpreq.c:1905: Test failed: IXMLHTTPRequest is not available saxreader.c:5767: Test failed: Failed to create SAXXMLReader instance schema.c:511: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:669: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:670: Test failed: Failed to create a document. schema.c:672: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:673: Test failed: Failed to create schema collection. schema.c:789: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:790: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:791: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:793: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:884: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:885: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:886: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:888: Test failed: failed to create CLSID_XMLSchemaCache30 instance: 0x80004001 schema.c:889: Test failed: failed to create CLSID_XMLSchemaCache40 instance: 0x80004001 schema.c:1031: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1032: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1033: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1214: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1215: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1216: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1217: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1417: Test failed: failed to create CLSID_XMLSchemaCache40 instance: 0x80004001 schema.c:1494: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1536: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 schema.c:1569: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 schema.c:1658: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 xmldoc.c:518: Test failed: Failed to create XMLDocument instance xmlview.c:160: Test failed: Failed to create XMLView instance xmlview.c:220: Test failed: Failed to create XMLView instance
=== debiant (64 bit WoW report) ===
msxml3: domdoc.c:111: Test failed: class DOMDocument, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument2, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument2, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument30, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument30, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument40, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument40, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class DOMDocument60, iface IXMLDOMDocument3 not supported domdoc.c:111: Test failed: class FreeThreadedDOMDocument, iface IXMLDOMDocument not supported domdoc.c:111: Test failed: class FreeThreadedDOMDocument, iface IXMLDOMDocument2 not supported domdoc.c:111: Test failed: class XMLSchemaCache, iface IXMLDOMSchemaCollection not supported domdoc.c:13029: Test failed: DOMDocument2 is not supported. Skipping all tests. httpreq.c:1905: Test failed: IXMLHTTPRequest is not available saxreader.c:5767: Test failed: Failed to create SAXXMLReader instance schema.c:511: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:669: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:670: Test failed: Failed to create a document. schema.c:672: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:673: Test failed: Failed to create schema collection. schema.c:789: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:790: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:791: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:793: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:884: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:885: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:886: Test failed: failed to create CLSID_DOMDocument30 instance: 0x80004001 schema.c:888: Test failed: failed to create CLSID_XMLSchemaCache30 instance: 0x80004001 schema.c:889: Test failed: failed to create CLSID_XMLSchemaCache40 instance: 0x80004001 schema.c:1031: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1032: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1033: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1214: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1215: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1216: Test failed: failed to create CLSID_DOMDocument instance: 0x80004001 schema.c:1217: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1417: Test failed: failed to create CLSID_XMLSchemaCache40 instance: 0x80004001 schema.c:1494: Test failed: failed to create CLSID_XMLSchemaCache instance: 0x80004001 schema.c:1536: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 schema.c:1569: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 schema.c:1658: Test failed: failed to create CLSID_XMLSchemaCache60 instance: 0x80004001 xmldoc.c:518: Test failed: Failed to create XMLDocument instance xmlview.c:160: Test failed: Failed to create XMLView instance xmlview.c:220: Test failed: Failed to create XMLView instance
On Sun, Apr 12, 2020 at 6:27 PM Zebediah Figura z.figura12@gmail.com wrote:
(2) not prompting for every add-on (personally I feel that two is already too many),
Now that you mention it, I can't think of any reason we couldn't combine the prompts for the addons we have. We just need someone to do the work. The hard part is giving appwiz.cpl the ability to test for all addons including in shared locations, and chaining the steps together.
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).
Maybe. The dependencies of those dependencies would also have to be loaded from system paths (builtin,distro,native search order?). We'd need the ability to use a list of paths for people who supply their own versions of the PE libraries, outside the paths controlled by the distribution. I'm not sure if we need to be concerned about how Windows programs will respond to seeing library dependencies resolved in a way that doesn't happen on Windows.
I still think an archive of PE dependencies has merit with this solution. You'd just have to extract it to /usr/local/, I guess.
On 4/12/20 8:00 PM, Esme (they/them) wrote:
On Sun, Apr 12, 2020 at 6:27 PM Zebediah Figura z.figura12@gmail.com wrote:
(2) not prompting for every add-on (personally I feel that two is already too many),
Now that you mention it, I can't think of any reason we couldn't combine the prompts for the addons we have. We just need someone to do the work. The hard part is giving appwiz.cpl the ability to test for all addons including in shared locations, and chaining the steps together.
Well, I guess one reason is they're not all necessary. Of course, Wine has a default position of "ship everything" anyway, so maybe I should just bite the bullet and accept that...
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).
Maybe. The dependencies of those dependencies would also have to be loaded from system paths (builtin,distro,native search order?). We'd need the ability to use a list of paths for people who supply their own versions of the PE libraries, outside the paths controlled by the distribution. I'm not sure if we need to be concerned about how Windows programs will respond to seeing library dependencies resolved in a way that doesn't happen on Windows.
I still think an archive of PE dependencies has merit with this solution. You'd just have to extract it to /usr/local/, I guess.
I guess it's not obvious to me there's a difference between "builtin" and "distro" (though we'd presumably not go putting the Wine builtin flag in mingw libraries). But yeah, I guess we'd want to vary load order depending on whether the library is a dependency of a PE builtin or not, in some way.
I guess it's not obvious to me there's a difference between "builtin" and "distro" (though we'd presumably not go putting the Wine builtin flag in mingw libraries). But yeah, I guess we'd want to vary load order depending on whether the library is a dependency of a PE builtin or not, in some way.
I was thinking about the possibility of a distro shipping a dll that's also a Wine builtin. But, we could probably resolve that case by saying "builtin" searches for wine builtins before distro libraries.
I guess we'd want the load order to be something like: * If explicitly set in registry or environment, use that. * If Wine builtin, use preattach. * If dependency of Wine builtin that exists in distro search path, builtin,native. * If dependency of a dll in distro search path (but not a Wine builtin), builtin,native. * Otherwise, native,builtin or maybe even native only (should Wine ever use a distro library to resolve dependencies of the application?).
On 4/12/20 8:56 PM, Esme (they/them) wrote:
I guess it's not obvious to me there's a difference between "builtin" and "distro" (though we'd presumably not go putting the Wine builtin flag in mingw libraries). But yeah, I guess we'd want to vary load order depending on whether the library is a dependency of a PE builtin or not, in some way.
I was thinking about the possibility of a distro shipping a dll that's also a Wine builtin. But, we could probably resolve that case by saying "builtin" searches for wine builtins before distro libraries.
I guess we'd want the load order to be something like:
- If explicitly set in registry or environment, use that.
- If Wine builtin, use preattach.
- If dependency of Wine builtin that exists in distro search path,
builtin,native.
- If dependency of a dll in distro search path (but not a Wine
builtin), builtin,native.
- Otherwise, native,builtin or maybe even native only (should Wine
ever use a distro library to resolve dependencies of the application?).
This last one is a good question. Would we necessarily expect an application-provided PE library to differ from a distro mingw library? (Maybe because of a lack of backwards compatibility?) To a degree it feels much like preferring builtin d3dx9 when the application provides its own.
It also kind of ties into bugs like 14980, 20777, 25373, 43472, 45551, 47053, 47120, 48275 where preferring builtin DLLs break applications. I recall that always preferring native breaks other applications, though I don't know any concrete examples... but since I have yet to hear a solution to this problem, I have to wonder if it would be better in general to use native,builtin for all direct dependencies of native DLLs.
(Presumably we'd want native,builtin rather than native only in any case. The number of cases where applications import DLLs but don't ship them is pretty small, in my experience? Though that doesn't include dynamically loading...)
On Sun, Apr 12, 2020 at 9:21 PM Zebediah Figura z.figura12@gmail.com wrote:
This last one is a good question. Would we necessarily expect an application-provided PE library to differ from a distro mingw library?
Yes, because of C runtime library versions. If the ABI includes a file handle or a malloc'd pointer, it depends on the C runtime it was compiled with. This is different from a Wine-provided dll because the Windows dll has a defined ABI.
There's also the possible scenario of: someone compiles a dll using mingw, it links to system libgcc provided by the distro, they test it on Wine, and it works even though it wouldn't on Windows.
On 4/13/20 4:13 AM, Zebediah Figura wrote:
On 4/12/20 8:56 PM, Esme (they/them) wrote:
I guess it's not obvious to me there's a difference between "builtin" and "distro" (though we'd presumably not go putting the Wine builtin flag in mingw libraries). But yeah, I guess we'd want to vary load order depending on whether the library is a dependency of a PE builtin or not, in some way.
I was thinking about the possibility of a distro shipping a dll that's also a Wine builtin. But, we could probably resolve that case by saying "builtin" searches for wine builtins before distro libraries.
I guess we'd want the load order to be something like: * If explicitly set in registry or environment, use that. * If Wine builtin, use preattach. * If dependency of Wine builtin that exists in distro search path, builtin,native. * If dependency of a dll in distro search path (but not a Wine builtin), builtin,native. * Otherwise, native,builtin or maybe even native only (should Wine ever use a distro library to resolve dependencies of the application?).
This last one is a good question. Would we necessarily expect an application-provided PE library to differ from a distro mingw library? (Maybe because of a lack of backwards compatibility?) To a degree it feels much like preferring builtin d3dx9 when the application provides its own.
It also kind of ties into bugs like 14980, 20777, 25373, 43472, 45551, 47053, 47120, 48275 where preferring builtin DLLs break applications. I recall that always preferring native breaks other applications, though I don't know any concrete examples... but since I have yet to hear a solution to this problem, I have to wonder if it would be better in general to use native,builtin for all direct dependencies of native DLLs.
(Presumably we'd want native,builtin rather than native only in any case. The number of cases where applications import DLLs but don't ship them is pretty small, in my experience? Though that doesn't include dynamically loading...)
I think it's a bit risky to assume that application provided DLL aren't going to collide with Wine dependencies expectations. As long as it's Windows DLL breakage, we can imagine that it's Wine's job to make it work, but third party DLLs is another story.
I think the idea of having Wine's internal dependencies isolated and not used for external dependencies resolution is a good thing. It's like the host dependencies -although they are provided by distributions- they stay invisible from the PE world.
So I think that although it could be seen as the architecturally "correct" approach, relying on distributions -or redistributed packages- to provide pristine PE versions of the dependencies is not going to work out.
Linux distributions already have quite a hard time factoring the dependencies and keeping all the Linux software working together nicely, and I think that doing the same for Windows software that was never written with such a setup in the first place -every application ships its with own dependencies isolated from the others- may be more painful than expected.
Cheers,
On 4/13/20 3:01 AM, Rémi Bernon wrote:
On 4/13/20 4:13 AM, Zebediah Figura wrote:
On 4/12/20 8:56 PM, Esme (they/them) wrote:
I guess it's not obvious to me there's a difference between "builtin" and "distro" (though we'd presumably not go putting the Wine builtin flag in mingw libraries). But yeah, I guess we'd want to vary load order depending on whether the library is a dependency of a PE builtin or not, in some way.
I was thinking about the possibility of a distro shipping a dll that's also a Wine builtin. But, we could probably resolve that case by saying "builtin" searches for wine builtins before distro libraries.
I guess we'd want the load order to be something like: * If explicitly set in registry or environment, use that. * If Wine builtin, use preattach. * If dependency of Wine builtin that exists in distro search path, builtin,native. * If dependency of a dll in distro search path (but not a Wine builtin), builtin,native. * Otherwise, native,builtin or maybe even native only (should Wine ever use a distro library to resolve dependencies of the application?).
This last one is a good question. Would we necessarily expect an application-provided PE library to differ from a distro mingw library? (Maybe because of a lack of backwards compatibility?) To a degree it feels much like preferring builtin d3dx9 when the application provides its own.
It also kind of ties into bugs like 14980, 20777, 25373, 43472, 45551, 47053, 47120, 48275 where preferring builtin DLLs break applications. I recall that always preferring native breaks other applications, though I don't know any concrete examples... but since I have yet to hear a solution to this problem, I have to wonder if it would be better in general to use native,builtin for all direct dependencies of native DLLs.
(Presumably we'd want native,builtin rather than native only in any case. The number of cases where applications import DLLs but don't ship them is pretty small, in my experience? Though that doesn't include dynamically loading...)
I think it's a bit risky to assume that application provided DLL aren't going to collide with Wine dependencies expectations. As long as it's Windows DLL breakage, we can imagine that it's Wine's job to make it work, but third party DLLs is another story.
I think the idea of having Wine's internal dependencies isolated and not used for external dependencies resolution is a good thing. It's like the host dependencies -although they are provided by distributions- they stay invisible from the PE world.
Sure, I can see why it's reasonable to always use builtin DLLs for dependencies of Wine builtins, and I'm not suggesting anything different...
So I think that although it could be seen as the architecturally "correct" approach, relying on distributions -or redistributed packages- to provide pristine PE versions of the dependencies is not going to work out.
...but I don't see how that implies that we can't use this approach for building and distributing them. Frankly, I can't see how it applies any approach. It does mean we have to do a bit of work to tweak the loader if we don't just statically link everything, but I don't think it'd end up being very much work.
Linux distributions already have quite a hard time factoring the dependencies and keeping all the Linux software working together nicely, and I think that doing the same for Windows software that was never written with such a setup in the first place -every application ships its with own dependencies isolated from the others- may be more painful than expected.
I'm not sure I understand: we wouldn't be managing dependencies for Windows software any more than we already are; we'd only be managing dependencies for Wine itself.l
Cheers,
On 13/04/2020 18:02, Zebediah Figura wrote:
On 4/13/20 3:01 AM, Rémi Bernon wrote:
Linux distributions already have quite a hard time factoring the dependencies and keeping all the Linux software working together nicely, and I think that doing the same for Windows software that was never written with such a setup in the first place -every application ships its with own dependencies isolated from the others- may be more painful than expected.
I'm not sure I understand: we wouldn't be managing dependencies for Windows software any more than we already are; we'd only be managing dependencies for Wine itself.l
Cheers,
FWIW, if this approach is chosen, I think they should first go (or be read in) somewhere in wine's directory, like other libs (or how Proton bundles its libs in <wine_dir>/lib{,64} for example) and the system-wide paths after that if those aren't found (or maybe not at all, because most distros don't even ship with mingw libraries... and I hate being reliant on this fact).
This is so you can use specific wine versions with specific libraries if you wish to do so, instead of a single system-wide choice for all versions. It also makes them potentially neatly stored in one place.
This is more important since you won't be able to use LD_LIBRARY_PATH or LD_PRELOAD either to "hack" the load order for debugging or any other reason.
Also, you'll be able to use Wine with older distros or otherwise more obscure ones that don't package them. Just drop it and run from its directory.
On 4/13/20 11:07 AM, Gabriel Ivăncescu wrote:
On 13/04/2020 18:02, Zebediah Figura wrote:
On 4/13/20 3:01 AM, Rémi Bernon wrote:
Linux distributions already have quite a hard time factoring the dependencies and keeping all the Linux software working together nicely, and I think that doing the same for Windows software that was never written with such a setup in the first place -every application ships its with own dependencies isolated from the others- may be more painful than expected.
I'm not sure I understand: we wouldn't be managing dependencies for Windows software any more than we already are; we'd only be managing dependencies for Wine itself.l
Cheers,
FWIW, if this approach is chosen, I think they should first go (or be read in) somewhere in wine's directory, like other libs (or how Proton bundles its libs in <wine_dir>/lib{,64} for example) and the system-wide paths after that if those aren't found (or maybe not at all, because most distros don't even ship with mingw libraries... and I hate being reliant on this fact).
I don't think this should be done. There's nothing Wine-specific about mingw libraries. Distributions I'm familiar with install them in paths like "/usr/i686-w64-mingw32/lib/libwhatever.so".
This is so you can use specific wine versions with specific libraries if you wish to do so, instead of a single system-wide choice for all versions. It also makes them potentially neatly stored in one place.
Ideally this wouldn't be necessary, because Unix libraries tend to be good at backwards compatibility, but if it is, I think it'd be potentially easier just to adjust this from the Wine side; probably it'd be as simple as changing the build order to "native,builtin" and supplying your own library somewhere in the path.
This is more important since you won't be able to use LD_LIBRARY_PATH or LD_PRELOAD either to "hack" the load order for debugging or any other reason.
Also, you'll be able to use Wine with older distros or otherwise more obscure ones that don't package them. Just drop it and run from its directory.
I think we're certainly going to have to package and distribute mingw libraries ourselves, at least for some distributions. But that doesn't mean we should make them Wine-specific.
On Mon, Apr 13, 2020 at 11:08 AM Gabriel Ivăncescu gabrielopcode@gmail.com wrote:
FWIW, if this approach is chosen, I think they should first go (or be read in) somewhere in wine's directory, like other libs (or how Proton bundles its libs in <wine_dir>/lib{,64} for example) and the system-wide paths after that if those aren't found (or maybe not at all, because most distros don't even ship with mingw libraries... and I hate being reliant on this fact).
If this approach is chosen, I intend to maintain a set of mingw libraries that can be used as an alternative to getting them from the distribution.
On Mon, Apr 13, 2020 at 10:08 AM Gabriel Ivăncescu gabrielopcode@gmail.com wrote:
... FWIW, if this approach is chosen, I think they should first go (or be read in) somewhere in wine's directory, like other libs (or how Proton bundles its libs in <wine_dir>/lib{,64} for example) and the system-wide paths after that if those aren't found (or maybe not at all, because most distros don't even ship with mingw libraries... and I hate being reliant on this fact).
This is so you can use specific wine versions with specific libraries if you wish to do so, instead of a single system-wide choice for all versions. It also makes them potentially neatly stored in one place.
This is more important since you won't be able to use LD_LIBRARY_PATH or LD_PRELOAD either to "hack" the load order for debugging or any other reason.
Also, you'll be able to use Wine with older distros or otherwise more obscure ones that don't package them. Just drop it and run from its directory.
Why don't we modify LoadLibrary and GetProcAddress to function as dlopen/dlsym when passed an ELF library? This should allow us to rework all our libraries in PE format without having to distribute a mess of dependencies, and still allow us to respect LD_LIBRARY_PATH and LD_PRELOAD settings.
Best, Erich
On 4/13/20 12:43 PM, Erich E. Hoover wrote:
On Mon, Apr 13, 2020 at 10:08 AM Gabriel Ivăncescu gabrielopcode@gmail.com wrote:
... FWIW, if this approach is chosen, I think they should first go (or be read in) somewhere in wine's directory, like other libs (or how Proton bundles its libs in <wine_dir>/lib{,64} for example) and the system-wide paths after that if those aren't found (or maybe not at all, because most distros don't even ship with mingw libraries... and I hate being reliant on this fact).
This is so you can use specific wine versions with specific libraries if you wish to do so, instead of a single system-wide choice for all versions. It also makes them potentially neatly stored in one place.
This is more important since you won't be able to use LD_LIBRARY_PATH or LD_PRELOAD either to "hack" the load order for debugging or any other reason.
Also, you'll be able to use Wine with older distros or otherwise more obscure ones that don't package them. Just drop it and run from its directory.
Why don't we modify LoadLibrary and GetProcAddress to function as dlopen/dlsym when passed an ELF library? This should allow us to rework all our libraries in PE format without having to distribute a mess of dependencies, and still allow us to respect LD_LIBRARY_PATH and LD_PRELOAD settings.
I guess that broadly this negates most of the advantages Esme enumerated in the first place. It makes converting our libraries to PE easier, but—
* we still have to (presumably manually) swap out of "PE mode" when making those calls (which, as I understand, will involve such things as saving thread context and swapping registers like aarch64's x18). Granted, we'd have to do this anyway for some libraries, but not having that overhead may also be helpful.
* we're still requiring both libfaudio.so and FAudio.dll (that Mono needs);
* I think we'd also run into problems with headers, since the ABI is diffferent. Granted, that might be easy to fix with compiler options (maybe just by not using -mabi=ms?)
Best, Erich
On 4/13/20 5:02 PM, Zebediah Figura wrote:
So I think that although it could be seen as the architecturally "correct" approach, relying on distributions -or redistributed packages- to provide pristine PE versions of the dependencies is not going to work out.
...but I don't see how that implies that we can't use this approach for building and distributing them. Frankly, I can't see how it applies any approach. It does mean we have to do a bit of work to tweak the loader if we don't just statically link everything, but I don't think it'd end up being very much work.
Sure, statically linking can also solve most issues here, assuming these dependencies do not require being dynamically linked.
But in the dynamic linking scenario, IIUC Wine currently offers only one choice: loading the builtin vs native version of a given DLL.
For instance, to illustrate, I understand that to properly manage SDL2 without conflict with an application shipping its own incompatible version of it, we would have to load these:
application.exe -> SDL2.dll (native) -> xaudio2_7.dll (builtin) -> FAudio.dll (builtin) -> SDL2.dll (builtin)
So we would have to decide whether to load SDL2 as builtin or native depending in which context it is loaded.
Then maybe I'm wrong but I understand that, currently, wine only handles the builtin vs native by always loading the requested version of the DLL, wherever it's loaded from, so would this contextual loading also apply to all libraries, or just the dependencies somehow?
Would it be something like a third possible option to native/builtin choice, like "load builtin if from a builtin / native if from native" setting? It seems a little bit convoluted to me to be honest when we can just rely on the existing mechanism and custom wine libraries.
A more troublesome issue I can think of with this approach: when investigating Denuvo protection, I could see that the DRM did some consistency checks for some selected libraries. And it did these checks by name, not caring about where the libraries were loaded from, but checking their contents against disk.
Now, pure guess here, but I can imagine that having two different DLLs loaded with the same name, and with a name that's possibly one of the selected libraries to check could cause some confusion and undesired trouble. Having internal wine dependencies live under a fake name could prevent future pain IMHO, especially when passing DRM checks is the main purpose for all this.
On 4/13/20 1:15 PM, Rémi Bernon wrote:
On 4/13/20 5:02 PM, Zebediah Figura wrote:
So I think that although it could be seen as the architecturally "correct" approach, relying on distributions -or redistributed packages- to provide pristine PE versions of the dependencies is not going to work out.
...but I don't see how that implies that we can't use this approach for building and distributing them. Frankly, I can't see how it applies any approach. It does mean we have to do a bit of work to tweak the loader if we don't just statically link everything, but I don't think it'd end up being very much work.
Sure, statically linking can also solve most issues here, assuming these dependencies do not require being dynamically linked.
But in the dynamic linking scenario, IIUC Wine currently offers only one choice: loading the builtin vs native version of a given DLL.
For instance, to illustrate, I understand that to properly manage SDL2 without conflict with an application shipping its own incompatible version of it, we would have to load these:
application.exe -> SDL2.dll (native) -> xaudio2_7.dll (builtin) -> FAudio.dll (builtin) -> SDL2.dll (builtin)
So we would have to decide whether to load SDL2 as builtin or native depending in which context it is loaded.
Then maybe I'm wrong but I understand that, currently, wine only handles the builtin vs native by always loading the requested version of the DLL, wherever it's loaded from, so would this contextual loading also apply to all libraries, or just the dependencies somehow?
Would it be something like a third possible option to native/builtin choice, like "load builtin if from a builtin / native if from native" setting? It seems a little bit convoluted to me to be honest when we can just rely on the existing mechanism and custom wine libraries.
What I'm imagining is that the default—when no explicit overrides are set in the registry or on the command line—is "builtin if from builtin, native if from native"; otherwise we just respect the override. This seems like a potentially reasonable approach to me in general, even for PE builtins (like d3dx*). But I'm not as married to it as I am to the question of how we build and distribute the libraries.
A more troublesome issue I can think of with this approach: when investigating Denuvo protection, I could see that the DRM did some consistency checks for some selected libraries. And it did these checks by name, not caring about where the libraries were loaded from, but checking their contents against disk.
Now, pure guess here, but I can imagine that having two different DLLs loaded with the same name, and with a name that's possibly one of the selected libraries to check could cause some confusion and undesired trouble. Having internal wine dependencies live under a fake name could prevent future pain IMHO, especially when passing DRM checks is the main purpose for all this.
If that is a problem, I think it's something we could get around with sxs, or indeed renaming the library. Though the latter may cause some pain regarding building. But given that sxs exists, I don't know that we necessarily need to assume it's a problem.
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.
Hi Zebediah,
I really think we should at least experiment and evaluate using winelib first. My previous mail didn't really explain details behind this and was a bit messy, so let me try now.
First, the name mingw or mingw-w64 is used to name different things depending on the context. For sake of this mail, let me use it to call the complete toolchain for (cross, but not only) compiling a Window target. mingw based on GCC contains following parts from different projects (LLVM mingw variant is similar, except that llvm/clang is always a cross compiler, so this part doesn't need to be built with mingw in mind and instead a fairly regular build can be used):
- GCC + binutils tools built with mingw as a target (from gcc and binutils tree) - libgcc cross compiled for mingw target (from gcc tree, but depends on crt part of mingw-w64) - crt headers (from mingw-w64 repo) - crt static libraries and startup files (libmingwex, libmingw32, libmsvcrt, etc, from mingw-w64 repo) - platform headers (from mingw-w64 repo) - platform importlibs (from mingw-w64 repo) - optionally winpthreads, which messes with crt headers and crt libs (from mingw-w64 repo) - libstdc++ and a few more component not important for sake of this conversation
Wine is not a typical mingw user, because it actually implements the platform for which it builds. As such, we need to provide majority of the stuff that other projects would use from mingw-w64. Initially, Wine used an exotic mix for crt: it used its own headers and msvcrt importlib, but mingw-w64 for the rest of static libs and startup files. It meant that Wine dependent on mingw-w64 internals that it shouldn't touch. mingw-w64 assumes that crt headers + crt libs are shipped together and it has the right to do so. It worked, but it was fragile. Anything that Wine didn't take into account (like configuring mingw-w64 to use ucrt by default) could cause a problem. It's probably just a matter of time when wine-5.0 will not build with future mingw-w64 releases and it will not be mingw-w64's fault.
We looked for a solution to that problem. One way to solve this would be tightening projects relationships. It's wasn't clear how technically that could look, but we had to put that idea aside for non-technical reasons anyway.
The other solution is to not mix crt parts at all. This required Wine to provide the few missing bits (mostly startup files) by itself. I'd say that it makes sense: we provide similar things for ELF builds anyway and we provide msvcrt implementation and headers, it feels natural to provide static library bits as well. Since February (or August last year for majority of the codebase), Wine does not use any part of mingw-w64 repo directly at all. We always use our own headers and -nodefaultlibs. Wine cross toolchain dependency is reduced to just GCC + binutils + libgcc (and mingw-w64 as build time libgcc dependency) from the list above. That's what you get with winegcc -mno-cygwin (without -mno-cygwin, we still use the exotic mix for mingw targets and we still use that for PE-only builds).
So now that we have this powerful tool and successfully use it for Wine build, it feels natural and technically right to use it for the rest of Wine ecosystem. What you propose would instead bring back mixing crt parts. Linking current Wine against external mingw-compiled (as opposed to winegcc -mno-cygwin) library is essentially linking a static lib with a different ABI. Headers should mostly work, but it's still shaky.
I didn't try winegcc yet with non-Wine code myself mostly because I still think there are things that we should get right first. My ucrt work was partially motivated by this. We should be able to default to ucrt in winegcc now (we already do that for Wine in makedep, so I'd say we're ready for that). There are a few other things, but we're getting there.
On 13.04.2020 01:18, 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:
Some of those are not obvious and will need a separated discussion, but let's not distract from the main topic for now. I think that the list will look somewhat like this.
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),
I think that fully functional Wine is the right default. If you think about addons as a part of Wine ecosystem, it's not much different from requiring the user to install jscript.dll even if they don't need it.
(2) not prompting for every add-on (personally I feel that two is already too many),
Sure, it would be nice to improve user experience with Wine addons. The reason I'm not motivated to work on it myself is that it's really just a fallback. If distro does its job well (and I think most of distros do), users don't need that anyway. IMHO we should concentrate on making it easy for distros to ship addons themselves, but fallback improvements are welcomed as well.
(3) letting the distribution choose what to distribute by default.
Sure, it should be possible to disable things at build time. Just like it's already possible to disable jscript.dll at build time.
* 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).
Yes, some distros provide such packages and it's nice. I happened to contribute to that on mingw-w64 side. The purpose of those packages is, however, different than what we need for Wine. It's meant to provide a nice way for cross compiling projects with open source dependences. And once you cross compile such an application and want to ship it, you need to copy required DLLs or statically link dependencies. It's a very different goal than assembling Windows distro that we need.
What you propose is essentially forcing packagers to assembly and Windows (Wine) distro and I don't like that. Linux distros should concentrate on providing good native userspace and it's Wine's responsibility to use that to provide Windows-compatible environment. The fact that we will leverage PE build of some project should be something that packager can control, but he should not be forced to take care and maintain 20 packages only for Wine.
We definitely don't want such Wine dependences to be used in place of application provided DLLs with the same name. Renaming the library in build time seems like way cleaner way than any runtime heuristics that this thread led to.
Another thing where your solution can become a nightmare is ABI incompatibility. We don't control the dependencies and some of them are not ABI stable. We just need to accept it and make sure our solution takes that into account. So for example, when something like this happens (I don't think this is an isolated example, but I happen to know about it and it's hilarious: they had an incompatible MSVC and mingw ABI, so decided to break and uglify mingw ABI to follow MSVC and hack around a problem that I believe is imaginary):
https://bugzilla.libsdl.org/show_bug.cgi?id=4771
What I propose is to have a solution where we just bump just one constant in one repo, which would make Wine use wine-sdl2-2.dll instead of wine-sdl2-1.dll and that's it. All distros are be happy.
What you propose is that now tens of distros would need to notice the problem and express it in their package dependences. It means tens of action tickets spread around the ecosystem and a few Wine NOTOURBUG bugs reported upstream. And all of that work is just to provide a library that's otherwise internal to Wine anyway.
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.
Well Mac would be even easier to target than it is now if we provide right tools (because some of those dependences are tricky on Mac already). And if some packagers really insist on splitting those packages, they can still do that. with what I proposed. They can use our build system as a 'driver' or do it manually, that's all fine. We'd be not forcing one way or another.
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
1. Not care, provide just wine-core package (addon headers are just a build time dependency). Wine will download and cache addons in runtime.
2. Use wine-core the way distro currently do to provide Wine package. Use wine-meta-distro to build Wine addons as one but separated package.
3. Use wine-meta-distro to produce both a fresh wine-core and wine addons package in a single step for a single package.
4. Like 2 or 3, but distro wants some customization itself. They can do that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
5. Split Wine into 20 packages. A distro can use wine-meta-distro to do build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
6. Split into 20 packages and deal with them without wine-meta-distro packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free.
Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
As a side note, a different and separated distro packages for, say, libxml2 built with winegcc could also have some use cases. That would be something potentially useful for cross compiling an application using winegcc, but not something for Wine to use internally.
Cheers,
Jacek
On 4/13/20 11:38 AM, Jacek Caban wrote:
Hi Zebediah,
I really think we should at least experiment and evaluate using winelib first. My previous mail didn't really explain details behind this and was a bit messy, so let me try now.
First, the name mingw or mingw-w64 is used to name different things depending on the context. For sake of this mail, let me use it to call the complete toolchain for (cross, but not only) compiling a Window target. mingw based on GCC contains following parts from different projects (LLVM mingw variant is similar, except that llvm/clang is always a cross compiler, so this part doesn't need to be built with mingw in mind and instead a fairly regular build can be used):
- GCC + binutils tools built with mingw as a target (from gcc and
binutils tree)
- libgcc cross compiled for mingw target (from gcc tree, but depends on
crt part of mingw-w64)
- crt headers (from mingw-w64 repo)
- crt static libraries and startup files (libmingwex, libmingw32,
libmsvcrt, etc, from mingw-w64 repo)
- platform headers (from mingw-w64 repo)
- platform importlibs (from mingw-w64 repo)
- optionally winpthreads, which messes with crt headers and crt libs
(from mingw-w64 repo)
- libstdc++ and a few more component not important for sake of this
conversation
Wine is not a typical mingw user, because it actually implements the platform for which it builds. As such, we need to provide majority of the stuff that other projects would use from mingw-w64. Initially, Wine used an exotic mix for crt: it used its own headers and msvcrt importlib, but mingw-w64 for the rest of static libs and startup files. It meant that Wine dependent on mingw-w64 internals that it shouldn't touch. mingw-w64 assumes that crt headers + crt libs are shipped together and it has the right to do so. It worked, but it was fragile. Anything that Wine didn't take into account (like configuring mingw-w64 to use ucrt by default) could cause a problem. It's probably just a matter of time when wine-5.0 will not build with future mingw-w64 releases and it will not be mingw-w64's fault.
We looked for a solution to that problem. One way to solve this would be tightening projects relationships. It's wasn't clear how technically that could look, but we had to put that idea aside for non-technical reasons anyway.
The other solution is to not mix crt parts at all. This required Wine to provide the few missing bits (mostly startup files) by itself. I'd say that it makes sense: we provide similar things for ELF builds anyway and we provide msvcrt implementation and headers, it feels natural to provide static library bits as well. Since February (or August last year for majority of the codebase), Wine does not use any part of mingw-w64 repo directly at all. We always use our own headers and -nodefaultlibs. Wine cross toolchain dependency is reduced to just GCC + binutils + libgcc (and mingw-w64 as build time libgcc dependency) from the list above. That's what you get with winegcc -mno-cygwin (without -mno-cygwin, we still use the exotic mix for mingw targets and we still use that for PE-only builds).
So now that we have this powerful tool and successfully use it for Wine build, it feels natural and technically right to use it for the rest of Wine ecosystem. What you propose would instead bring back mixing crt parts. Linking current Wine against external mingw-compiled (as opposed to winegcc -mno-cygwin) library is essentially linking a static lib with a different ABI. Headers should mostly work, but it's still shaky.
I didn't try winegcc yet with non-Wine code myself mostly because I still think there are things that we should get right first. My ucrt work was partially motivated by this. We should be able to default to ucrt in winegcc now (we already do that for Wine in makedep, so I'd say we're ready for that). There are a few other things, but we're getting there.
Admittedly I'm really unhappy with the way that discussion went; it seemed to die immediately before any discussion was made about *how* we could share code. I do think it was a mistake to try to take mingw under the umbrella of Wine—as I see it, mingw targets the Win32 API, and Wine is just one implementation—but I don't particularly understand how that precludes more sharing of headers, libraries, and even CRT bits. I know that you've done a lot of work to disentangle us from mingw libraries, but is there any technical reason why we can't go the other direction?
Even setting that aside, broadly a mingw library should work on Windows, so I'd expect it to work on Wine too (and since we're not talking about cygwin here, I think we can assume they won't do dumb things like alloca() several pages in DLL_PROCESS_ATTACH and expect that memory to remain untouched).
On 13.04.2020 01:18, 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:
Some of those are not obvious and will need a separated discussion, but let's not distract from the main topic for now. I think that the list will look somewhat like this.
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),
I think that fully functional Wine is the right default. If you think about addons as a part of Wine ecosystem, it's not much different from requiring the user to install jscript.dll even if they don't need it.
Yes, I suppose I had better accept that :-/
(2) not prompting for every add-on (personally I feel that two is already too many),
Sure, it would be nice to improve user experience with Wine addons. The reason I'm not motivated to work on it myself is that it's really just a fallback. If distro does its job well (and I think most of distros do), users don't need that anyway. IMHO we should concentrate on making it easy for distros to ship addons themselves, but fallback improvements are welcomed as well.
(3) letting the distribution choose what to distribute by default.
Sure, it should be possible to disable things at build time. Just like it's already possible to disable jscript.dll at build time.
* 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).
Yes, some distros provide such packages and it's nice. I happened to contribute to that on mingw-w64 side. The purpose of those packages is, however, different than what we need for Wine. It's meant to provide a nice way for cross compiling projects with open source dependences. And once you cross compile such an application and want to ship it, you need to copy required DLLs or statically link dependencies. It's a very different goal than assembling Windows distro that we need.
It's not clear to me that it is that different, though. We're also cross-compiling high-level code with open-source dependencies, like windowscodecs. The only difference is that we're also shipping the reimplementation of the lower-level code and the loader. To illustrate that it's pretty much the same thing, I think it should even be possible to e.g. use wine's windowscodecs on a real Windows box, after copying over the dependencies. Frankly, the only difference I see with regard to wineprefixes is that we don't necessarily have to copy the system libraries into the wineprefix.
What you propose is essentially forcing packagers to assembly and Windows (Wine) distro and I don't like that. Linux distros should concentrate on providing good native userspace and it's Wine's responsibility to use that to provide Windows-compatible environment. The fact that we will leverage PE build of some project should be something that packager can control, but he should not be forced to take care and maintain 20 packages only for Wine.
Sure, I don't see a problem with letting the packaging be Wine's responsibility, if Wine is the only user. That doesn't mean that we can't follow the existing model for mingw packages, though.
We definitely don't want such Wine dependences to be used in place of application provided DLLs with the same name. Renaming the library in build time seems like way cleaner way than any runtime heuristics that this thread led to.
I'm not sure I agree with this (obviously we do want to use native versions where the application provides them, but I'm not sure I see how renaming is necessarily cleaner), but it's pretty much a separate issue so I'll leave it aside for now.
Another thing where your solution can become a nightmare is ABI incompatibility. We don't control the dependencies and some of them are not ABI stable. We just need to accept it and make sure our solution takes that into account. So for example, when something like this happens (I don't think this is an isolated example, but I happen to know about it and it's hilarious: they had an incompatible MSVC and mingw ABI, so decided to break and uglify mingw ABI to follow MSVC and hack around a problem that I believe is imaginary):
https://bugzilla.libsdl.org/show_bug.cgi?id=4771
What I propose is to have a solution where we just bump just one constant in one repo, which would make Wine use wine-sdl2-2.dll instead of wine-sdl2-1.dll and that's it. All distros are be happy.
What you propose is that now tens of distros would need to notice the problem and express it in their package dependences. It means tens of action tickets spread around the ecosystem and a few Wine NOTOURBUG bugs reported upstream. And all of that work is just to provide a library that's otherwise internal to Wine anyway.
I think I may have poorly communicated—I don't think it necessarily has to be the distribution's job to package mingw libraries. Of course it's nicer if they do—and if there's already distribution libraries I think we can use them—but I'm fully expecting that we'll have to package most libraries for most distributions, for a time if not in perpetuity. If we're the only user of those libraries I think that's reasonable.
Hence ABI incompatibility is dealt with the same way it usually is, by requiring specific library versions. If we have to build and ship separate versions because the distribution's version is out of date, well, that's the life we already have to live :-/
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.
Well Mac would be even easier to target than it is now if we provide right tools (because some of those dependences are tricky on Mac already). And if some packagers really insist on splitting those packages, they can still do that. with what I proposed. They can use our build system as a 'driver' or do it manually, that's all fine. We'd be not forcing one way or another.
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- Use wine-core the way distro currently do to provide Wine package.
Use wine-meta-distro to build Wine addons as one but separated package.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- Like 2 or 3, but distro wants some customization itself. They can do
that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
- Split Wine into 20 packages. A distro can use wine-meta-distro to do
build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
- Split into 20 packages and deal with them without wine-meta-distro
packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free.
Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
Pretty much 5, I think. If I understand correctly, 6 is only true when distributions are already shipping mingw packages (and only for those packages), in which case they're not really redoing any work.
I don't work in distributions, but I don't particularly understand why 5 is any harder than 2-4, or what's gained from having 2-4 as an option.
As a side note, a different and separated distro packages for, say, libxml2 built with winegcc could also have some use cases. That would be something potentially useful for cross compiling an application using winegcc, but not something for Wine to use internally.
Cheers,
Jacek
On 13.04.2020 19:38, Zebediah Figura wrote:
On 4/13/20 11:38 AM, Jacek Caban wrote:
Hi Zebediah,
I really think we should at least experiment and evaluate using winelib first. My previous mail didn't really explain details behind this and was a bit messy, so let me try now.
First, the name mingw or mingw-w64 is used to name different things depending on the context. For sake of this mail, let me use it to call the complete toolchain for (cross, but not only) compiling a Window target. mingw based on GCC contains following parts from different projects (LLVM mingw variant is similar, except that llvm/clang is always a cross compiler, so this part doesn't need to be built with mingw in mind and instead a fairly regular build can be used):
- GCC + binutils tools built with mingw as a target (from gcc and
binutils tree)
- libgcc cross compiled for mingw target (from gcc tree, but depends on
crt part of mingw-w64)
- crt headers (from mingw-w64 repo)
- crt static libraries and startup files (libmingwex, libmingw32,
libmsvcrt, etc, from mingw-w64 repo)
- platform headers (from mingw-w64 repo)
- platform importlibs (from mingw-w64 repo)
- optionally winpthreads, which messes with crt headers and crt libs
(from mingw-w64 repo)
- libstdc++ and a few more component not important for sake of this
conversation
Wine is not a typical mingw user, because it actually implements the platform for which it builds. As such, we need to provide majority of the stuff that other projects would use from mingw-w64. Initially, Wine used an exotic mix for crt: it used its own headers and msvcrt importlib, but mingw-w64 for the rest of static libs and startup files. It meant that Wine dependent on mingw-w64 internals that it shouldn't touch. mingw-w64 assumes that crt headers + crt libs are shipped together and it has the right to do so. It worked, but it was fragile. Anything that Wine didn't take into account (like configuring mingw-w64 to use ucrt by default) could cause a problem. It's probably just a matter of time when wine-5.0 will not build with future mingw-w64 releases and it will not be mingw-w64's fault.
We looked for a solution to that problem. One way to solve this would be tightening projects relationships. It's wasn't clear how technically that could look, but we had to And that's true for both way of doing it. put that idea aside for non-technical reasons anyway.
The other solution is to not mix crt parts at all. This required Wine to provide the few missing bits (mostly startup files) by itself. I'd say that it makes sense: we provide similar things for ELF builds anyway and we provide msvcrt implementation and headers, it feels natural to provide static library bits as well. Since February (or August last year for majority of the codebase), Wine does not use any part of mingw-w64 repo directly at all. We always use our own headers and -nodefaultlibs. Wine cross toolchain dependency is reduced to just GCC + binutils + libgcc (and mingw-w64 as build time libgcc dependency) from the list above. That's what you get with winegcc -mno-cygwin (without -mno-cygwin, we still use the exotic mix for mingw targets and we still use that for PE-only builds).
So now that we have this powerful tool and successfully use it for Wine build, it feels natural and technically right to use it for the rest of Wine ecosystem. What you propose would instead bring back mixing crt parts. Linking current Wine against external mingw-compiled (as opposed to winegcc -mno-cygwin) library is essentially linking a static lib with a different ABI. Headers should mostly work, but it's still shaky.
I didn't try winegcc yet with non-Wine code myself mostly because I still think there are things that we should get right first. My ucrt work was partially motivated by this. We should be able to default to ucrt in winegcc now (we already do that for Wine in makedep, so I'd say we're ready for that). There are a few other things, but we're getting there.
Admittedly I'm really unhappy with the way that discussion went; it seemed to die immediately before any discussion was made about *how* we could share code. I do think it was a mistake to try to take mingw under the umbrella of Wine—as I see it, mingw targets the Win32 API, and Wine is just one implementation—
That's one way to look at it. I'd say that implementation and SDK for the implementation fit naturally together (just like Microsoft provides both implementation and SDK of Win32 API).
but I don't particularly understand how that precludes more sharing of headers, libraries, and even CRT bits. I know that you've done a lot of work to disentangle us from mingw libraries, but is there any technical reason why we can't go the other direction?
I don't see how that could be done without bad effects on the workflow. What would you do if you wanted to add a trivial test for a new API? One that currently would take a few minutes to write and a single patch to send.
Even setting that aside, broadly a mingw library should work on Windows, so I'd expect it to work on Wine too (and since we're not talking about cygwin here, I think we can assume they won't do dumb things like alloca() several pages in DLL_PROCESS_ATTACH and expect that memory to remain untouched).
I think I explained why it would be wrong for static libs. If you mean when built as a separated DLL, it would work in most cases, yes. That's assuming that library's API doesn't expose things like fds, FILEs, etc.
On 13.04.2020 01:18, 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:
Some of those are not obvious and will need a separated discussion, but let's not distract from the main topic for now. I think that the list will look somewhat like this.
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),
I think that fully functional Wine is the right default. If you think about addons as a part of Wine ecosystem, it's not much different from requiring the user to install jscript.dll even if they don't need it.
Yes, I suppose I had better accept that :-/
(2) not prompting for every add-on (personally I feel that two is already too many),
Sure, it would be nice to improve user experience with Wine addons. The reason I'm not motivated to work on it myself is that it's really just a fallback. If distro does its job well (and I think most of distros do), users don't need that anyway. IMHO we should concentrate on making it easy for distros to ship addons themselves, but fallback improvements are welcomed as well.
(3) letting the distribution choose what to distribute by default.
Sure, it should be possible to disable things at build time. Just like it's already possible to disable jscript.dll at build time.
* 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).
Yes, some distros provide such packages and it's nice. I happened to contribute to that on mingw-w64 side. The purpose of those packages is, however, different than what we need for Wine. It's meant to provide a nice way for cross compiling projects with open source dependences. And once you cross compile such an application and want to ship it, you need to copy required DLLs or statically link dependencies. It's a very different goal than assembling Windows distro that we need.
It's not clear to me that it is that different, though. We're also cross-compiling high-level code with open-source dependencies, like windowscodecs. The only difference is that we're also shipping the reimplementation of the lower-level code and the loader. To illustrate that it's pretty much the same thing, I think it should even be possible to e.g. use wine's windowscodecs on a real Windows box, after copying over the dependencies. Frankly, the only difference I see with regard to wineprefixes is that we don't necessarily have to copy the system libraries into the wineprefix.
I don't negate that it will work. I'm just saying that I don't think it's technically the best way of doing it.
What you propose is essentially forcing packagers to assembly and Windows (Wine) distro and I don't like that. Linux distros should concentrate on providing good native userspace and it's Wine's responsibility to use that to provide Windows-compatible environment. The fact that we will leverage PE build of some project should be something that packager can control, but he should not be forced to take care and maintain 20 packages only for Wine.
Sure, I don't see a problem with letting the packaging be Wine's responsibility, if Wine is the only user. That doesn't mean that we can't follow the existing model for mingw packages, though.
We definitely don't want such Wine dependences to be used in place of application provided DLLs with the same name. Renaming the library in build time seems like way cleaner way than any runtime heuristics that this thread led to.
I'm not sure I agree with this (obviously we do want to use native versions where the application provides them, but I'm not sure I see how renaming is necessarily cleaner), but it's pretty much a separate issue so I'll leave it aside for now.
Another thing where your solution can become a nightmare is ABI incompatibility. We don't control the dependencies and some of them are not ABI stable. We just need to accept it and make sure our solution takes that into account. So for example, when something like this happens (I don't think this is an isolated example, but I happen to know about it and it's hilarious: they had an incompatible MSVC and mingw ABI, so decided to break and uglify mingw ABI to follow MSVC and hack around a problem that I believe is imaginary):
https://bugzilla.libsdl.org/show_bug.cgi?id=4771
What I propose is to have a solution where we just bump just one constant in one repo, which would make Wine use wine-sdl2-2.dll instead of wine-sdl2-1.dll and that's it. All distros are be happy.
What you propose is that now tens of distros would need to notice the problem and express it in their package dependences. It means tens of action tickets spread around the ecosystem and a few Wine NOTOURBUG bugs reported upstream. And all of that work is just to provide a library that's otherwise internal to Wine anyway.
I think I may have poorly communicated—I don't think it necessarily has to be the distribution's job to package mingw libraries. Of course it's nicer if they do—and if there's already distribution libraries I think we can use them—but I'm fully expecting that we'll have to package most libraries for most distributions, for a time if not in perpetuity. If we're the only user of those libraries I think that's reasonable.
Well, my hope is that distros will like it and adopt it themselves. If building the whole thing is as easy as pulling wine-meta-distro and running:
./configure; make; make install
and get fully functional Wine with all PE dependences, I hope distros will choose to use it. We've been there when we introduced Wine Gecko. I think the ecosystem is in much better shape now and adaptation may be much smoother.
Still, we will need to provide those dependences in our packages as well. But if we make it easy for distro packagers, it will be easy for us as well (or, well, the another way around).
Hence ABI incompatibility is dealt with the same way it usually is, by requiring specific library versions. If we have to build and ship separate versions because the distribution's version is out of date, well, that's the life we already have to live :-/
If a solution helps to avoid dealing with that, I'd say it's a good thing. Also, on Linux, there are common practices like different .so suffices for ABI version. There is no such thing on Windows. What I proposed is really doing an analogous thing.
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.
Well Mac would be even easier to target than it is now if we provide right tools (because some of those dependences are tricky on Mac already). And if some packagers really insist on splitting those packages, they can still do that. with what I proposed. They can use our build system as a 'driver' or do it manually, that's all fine. We'd be not forcing one way or another.
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- Use wine-core the way distro currently do to provide Wine package.
Use wine-meta-distro to build Wine addons as one but separated package.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- Like 2 or 3, but distro wants some customization itself. They can do
that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
- Split Wine into 20 packages. A distro can use wine-meta-distro to do
build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
- Split into 20 packages and deal with them without wine-meta-distro
packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free.
Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
Pretty much 5, I think. If I understand correctly, 6 is only true when distributions are already shipping mingw packages (and only for those packages), in which case they're not really redoing any work.
The other important part of 5 is that you can build all those packages in a combination of versions that are tested and guaranteed by community to work (unless packager chooses to do otherwise). My understanding is that you meant packagers to do arbitrary version choices by default.
I don't work in distributions, but I don't particularly understand why 5 is any harder than 2-4, or what's gained from having 2-4 as an option.
The gain from 2-4 is simplicity that I mentioned earlier, which I think is crucial if we want wide adaptation. What's gained by 5?
Jacek
On 4/13/20 2:17 PM, Jacek Caban wrote:
On 13.04.2020 19:38, Zebediah Figura wrote:
On 4/13/20 11:38 AM, Jacek Caban wrote:
Hi Zebediah,
I really think we should at least experiment and evaluate using winelib first. My previous mail didn't really explain details behind this and was a bit messy, so let me try now.
First, the name mingw or mingw-w64 is used to name different things depending on the context. For sake of this mail, let me use it to call the complete toolchain for (cross, but not only) compiling a Window target. mingw based on GCC contains following parts from different projects (LLVM mingw variant is similar, except that llvm/clang is always a cross compiler, so this part doesn't need to be built with mingw in mind and instead a fairly regular build can be used):
- GCC + binutils tools built with mingw as a target (from gcc and
binutils tree)
- libgcc cross compiled for mingw target (from gcc tree, but depends on
crt part of mingw-w64)
- crt headers (from mingw-w64 repo)
- crt static libraries and startup files (libmingwex, libmingw32,
libmsvcrt, etc, from mingw-w64 repo)
- platform headers (from mingw-w64 repo)
- platform importlibs (from mingw-w64 repo)
- optionally winpthreads, which messes with crt headers and crt libs
(from mingw-w64 repo)
- libstdc++ and a few more component not important for sake of this
conversation
Wine is not a typical mingw user, because it actually implements the platform for which it builds. As such, we need to provide majority of the stuff that other projects would use from mingw-w64. Initially, Wine used an exotic mix for crt: it used its own headers and msvcrt importlib, but mingw-w64 for the rest of static libs and startup files. It meant that Wine dependent on mingw-w64 internals that it shouldn't touch. mingw-w64 assumes that crt headers + crt libs are shipped together and it has the right to do so. It worked, but it was fragile. Anything that Wine didn't take into account (like configuring mingw-w64 to use ucrt by default) could cause a problem. It's probably just a matter of time when wine-5.0 will not build with future mingw-w64 releases and it will not be mingw-w64's fault.
We looked for a solution to that problem. One way to solve this would be tightening projects relationships. It's wasn't clear how technically that could look, but we had to And that's true for both way of doing it. put that idea aside for non-technical reasons anyway.
The other solution is to not mix crt parts at all. This required Wine to provide the few missing bits (mostly startup files) by itself. I'd say that it makes sense: we provide similar things for ELF builds anyway and we provide msvcrt implementation and headers, it feels natural to provide static library bits as well. Since February (or August last year for majority of the codebase), Wine does not use any part of mingw-w64 repo directly at all. We always use our own headers and -nodefaultlibs. Wine cross toolchain dependency is reduced to just GCC + binutils + libgcc (and mingw-w64 as build time libgcc dependency) from the list above. That's what you get with winegcc -mno-cygwin (without -mno-cygwin, we still use the exotic mix for mingw targets and we still use that for PE-only builds).
So now that we have this powerful tool and successfully use it for Wine build, it feels natural and technically right to use it for the rest of Wine ecosystem. What you propose would instead bring back mixing crt parts. Linking current Wine against external mingw-compiled (as opposed to winegcc -mno-cygwin) library is essentially linking a static lib with a different ABI. Headers should mostly work, but it's still shaky.
I didn't try winegcc yet with non-Wine code myself mostly because I still think there are things that we should get right first. My ucrt work was partially motivated by this. We should be able to default to ucrt in winegcc now (we already do that for Wine in makedep, so I'd say we're ready for that). There are a few other things, but we're getting there.
Admittedly I'm really unhappy with the way that discussion went; it seemed to die immediately before any discussion was made about *how* we could share code. I do think it was a mistake to try to take mingw under the umbrella of Wine—as I see it, mingw targets the Win32 API, and Wine is just one implementation—
That's one way to look at it. I'd say that implementation and SDK for the implementation fit naturally together (just like Microsoft provides both implementation and SDK of Win32 API).
To a degree, though
(1) most things built with mingw are not built to run on Wine;
(2) anything with mingw has the ability to run on any implementation, at least in theory;
(3) Wine isn't even the only open-source implementation of Win32;
(4) I imagine we'd all be using Microsoft SDK headers if they weren't copyrighted.
but I don't particularly understand how that precludes more sharing of headers, libraries, and even CRT bits. I know that you've done a lot of work to disentangle us from mingw libraries, but is there any technical reason why we can't go the other direction?
I don't see how that could be done without bad effects on the workflow. What would you do if you wanted to add a trivial test for a new API? One that currently would take a few minutes to write and a single patch to send.
That is a good point. In my experience mingw is pretty quick to review and commit patches, but awfully slow to release new versions. Maybe that's something that could be improved, though.
Even setting that aside, broadly a mingw library should work on Windows, so I'd expect it to work on Wine too (and since we're not talking about cygwin here, I think we can assume they won't do dumb things like alloca() several pages in DLL_PROCESS_ATTACH and expect that memory to remain untouched).
I think I explained why it would be wrong for static libs. If you mean when built as a separated DLL, it would work in most cases, yes. That's assuming that library's API doesn't expose things like fds, FILEs, etc.
Sure, I was assuming dynamic libraries.
As long as we link to the right CRT version I guess we shouldn't have trouble. I have to presume that's something that any mingw user would have to worry about anyway.
On 13.04.2020 01:18, 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:
Some of those are not obvious and will need a separated discussion, but let's not distract from the main topic for now. I think that the list will look somewhat like this.
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),
I think that fully functional Wine is the right default. If you think about addons as a part of Wine ecosystem, it's not much different from requiring the user to install jscript.dll even if they don't need it.
Yes, I suppose I had better accept that :-/
(2) not prompting for every add-on (personally I feel that two is already too many),
Sure, it would be nice to improve user experience with Wine addons. The reason I'm not motivated to work on it myself is that it's really just a fallback. If distro does its job well (and I think most of distros do), users don't need that anyway. IMHO we should concentrate on making it easy for distros to ship addons themselves, but fallback improvements are welcomed as well.
(3) letting the distribution choose what to distribute by default.
Sure, it should be possible to disable things at build time. Just like it's already possible to disable jscript.dll at build time.
* 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).
Yes, some distros provide such packages and it's nice. I happened to contribute to that on mingw-w64 side. The purpose of those packages is, however, different than what we need for Wine. It's meant to provide a nice way for cross compiling projects with open source dependences. And once you cross compile such an application and want to ship it, you need to copy required DLLs or statically link dependencies. It's a very different goal than assembling Windows distro that we need.
It's not clear to me that it is that different, though. We're also cross-compiling high-level code with open-source dependencies, like windowscodecs. The only difference is that we're also shipping the reimplementation of the lower-level code and the loader. To illustrate that it's pretty much the same thing, I think it should even be possible to e.g. use wine's windowscodecs on a real Windows box, after copying over the dependencies. Frankly, the only difference I see with regard to wineprefixes is that we don't necessarily have to copy the system libraries into the wineprefix.
I don't negate that it will work. I'm just saying that I don't think it's technically the best way of doing it.
What you propose is essentially forcing packagers to assembly and Windows (Wine) distro and I don't like that. Linux distros should concentrate on providing good native userspace and it's Wine's responsibility to use that to provide Windows-compatible environment. The fact that we will leverage PE build of some project should be something that packager can control, but he should not be forced to take care and maintain 20 packages only for Wine.
Sure, I don't see a problem with letting the packaging be Wine's responsibility, if Wine is the only user. That doesn't mean that we can't follow the existing model for mingw packages, though.
We definitely don't want such Wine dependences to be used in place of application provided DLLs with the same name. Renaming the library in build time seems like way cleaner way than any runtime heuristics that this thread led to.
I'm not sure I agree with this (obviously we do want to use native versions where the application provides them, but I'm not sure I see how renaming is necessarily cleaner), but it's pretty much a separate issue so I'll leave it aside for now.
Another thing where your solution can become a nightmare is ABI incompatibility. We don't control the dependencies and some of them are not ABI stable. We just need to accept it and make sure our solution takes that into account. So for example, when something like this happens (I don't think this is an isolated example, but I happen to know about it and it's hilarious: they had an incompatible MSVC and mingw ABI, so decided to break and uglify mingw ABI to follow MSVC and hack around a problem that I believe is imaginary):
https://bugzilla.libsdl.org/show_bug.cgi?id=4771
What I propose is to have a solution where we just bump just one constant in one repo, which would make Wine use wine-sdl2-2.dll instead of wine-sdl2-1.dll and that's it. All distros are be happy.
What you propose is that now tens of distros would need to notice the problem and express it in their package dependences. It means tens of action tickets spread around the ecosystem and a few Wine NOTOURBUG bugs reported upstream. And all of that work is just to provide a library that's otherwise internal to Wine anyway.
I think I may have poorly communicated—I don't think it necessarily has to be the distribution's job to package mingw libraries. Of course it's nicer if they do—and if there's already distribution libraries I think we can use them—but I'm fully expecting that we'll have to package most libraries for most distributions, for a time if not in perpetuity. If we're the only user of those libraries I think that's reasonable.
Well, my hope is that distros will like it and adopt it themselves. If building the whole thing is as easy as pulling wine-meta-distro and running:
./configure; make; make install
and get fully functional Wine with all PE dependences, I hope distros will choose to use it. We've been there when we introduced Wine Gecko. I think the ecosystem is in much better shape now and adaptation may be much smoother.
Still, we will need to provide those dependences in our packages as well. But if we make it easy for distro packagers, it will be easy for us as well (or, well, the another way around).
Right, I forsee it'd be as simple as that using mingw structure as well. You'd just also have to install the package(s). We could even make a 'wine-common' dummy package that pulls in all of the dependencies, I guess.
Hence ABI incompatibility is dealt with the same way it usually is, by requiring specific library versions. If we have to build and ship separate versions because the distribution's version is out of date, well, that's the life we already have to live :-/
If a solution helps to avoid dealing with that, I'd say it's a good thing. Also, on Linux, there are common practices like different .so suffices for ABI version. There is no such thing on Windows. What I proposed is really doing an analogous thing.
The way I see it, if we don't rely on mingw libraries / packages / structure, we have to build a specific version of everything anyway. If we do, we *might* have to build a specific version, if a library does break ABI.
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.
Well Mac would be even easier to target than it is now if we provide right tools (because some of those dependences are tricky on Mac already). And if some packagers really insist on splitting those packages, they can still do that. with what I proposed. They can use our build system as a 'driver' or do it manually, that's all fine. We'd be not forcing one way or another.
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- Use wine-core the way distro currently do to provide Wine package.
Use wine-meta-distro to build Wine addons as one but separated package.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- Like 2 or 3, but distro wants some customization itself. They can do
that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
- Split Wine into 20 packages. A distro can use wine-meta-distro to do
build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
- Split into 20 packages and deal with them without wine-meta-distro
packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free.
Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
Pretty much 5, I think. If I understand correctly, 6 is only true when distributions are already shipping mingw packages (and only for those packages), in which case they're not really redoing any work.
The other important part of 5 is that you can build all those packages in a combination of versions that are tested and guaranteed by community to work (unless packager chooses to do otherwise). My understanding is that you meant packagers to do arbitrary version choices by default.
I'm not admittedly sure what's meant by arbitrary version choices, or perhaps this paragraph in general, but I'm imagining that mingw packages will be no different than non-mingw packages in most respects, so we/distributions can do whatever testing is desired.
I don't work in distributions, but I don't particularly understand why 5 is any harder than 2-4, or what's gained from having 2-4 as an option.
The gain from 2-4 is simplicity that I mentioned earlier, which I think is crucial if we want wide adaptation. What's gained by 5?
Essentially, that it's the way things are already done.
I guess I'm also still not understanding why 2-4 is simpler, except I guess it doesn't require any packages to be installed as build dependencies—which doesn't seem like a huge advantage, since that's basically just the norm for package building.
Jacek
Ultimately I guess I should summarize my interest in all this:
* I'm generally in favor of working with an existing system rather than discarding it and reimplementing it;
* I'd really rather not have to build twenty libraries as part of building Wine (so I really don't like Rémi's proposal, or any proposal involving submodules);
* the less we have to rebuild (or re-download!) every time a core CRT header or static library gets changed, the better;
* while I understand that addons "should" be the responsibility of the distribution, currently my distribution doesn't handle them, and I do have to click "yes" every time; I'd rather not have to click "yes" more times (or be forced to change distributions, or have to upstream such a package);
* I'd rather not needlessly duplicate libraries in general, hence I don't like the idea of using static libraries or building Wine-specific versions. Wine may be the only user of most of these, though, so this point is not particularly salient.
On 13.04.2020 22:47, Zebediah Figura wrote:
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.
Well Mac would be even easier to target than it is now if we provide right tools (because some of those dependences are tricky on Mac already). And if some packagers really insist on splitting those packages, they can still do that. with what I proposed. They can use our build system as a 'driver' or do it manually, that's all fine. We'd be not forcing one way or another.
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- Use wine-core the way distro currently do to provide Wine package.
Use wine-meta-distro to build Wine addons as one but separated package.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- Like 2 or 3, but distro wants some customization itself. They can do
that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
- Split Wine into 20 packages. A distro can use wine-meta-distro to do
build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
- Split into 20 packages and deal with them without wine-meta-distro
packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free.
Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
Pretty much 5, I think. If I understand correctly, 6 is only true when distributions are already shipping mingw packages (and only for those packages), in which case they're not really redoing any work.
The other important part of 5 is that you can build all those packages in a combination of versions that are tested and guaranteed by community to work (unless packager chooses to do otherwise). My understanding is that you meant packagers to do arbitrary version choices by default.
I'm not admittedly sure what's meant by arbitrary version choices, or perhaps this paragraph in general, but I'm imagining that mingw packages will be no different than non-mingw packages in most respects, so we/distributions can do whatever testing is desired.
If you expect packagers to build 20 packages, they need to make 20 version choices about version and then update them as they see the fit.
I don't work in distributions, but I don't particularly understand why 5 is any harder than 2-4, or what's gained from having 2-4 as an option.
The gain from 2-4 is simplicity that I mentioned earlier, which I think is crucial if we want wide adaptation. What's gained by 5?
Essentially, that it's the way things are already done.
I guess I'm also still not understanding why 2-4 is simpler, except I guess it doesn't require any packages to be installed as build dependencies—which doesn't seem like a huge advantage, since that's basically just the norm for package building.
Let's use an example. Suppose I want to bootstrap a fully working Wine on a distro with no Wine or Wine-specific packages (or I just don't want to use them). I don't want to use any binary blob, so I need to build all PE dependences myself. How would my experience look like with what you propose?
Jacek
On 4/13/20 8:04 PM, Jacek Caban wrote:
On 13.04.2020 22:47, Zebediah Figura wrote:
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.
Well Mac would be even easier to target than it is now if we provide right tools (because some of those dependences are tricky on Mac already). And if some packagers really insist on splitting those packages, they can still do that. with what I proposed. They can use our build system as a 'driver' or do it manually, that's all fine. We'd be not forcing one way or another.
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- Use wine-core the way distro currently do to provide Wine package.
Use wine-meta-distro to build Wine addons as one but separated package.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- Like 2 or 3, but distro wants some customization itself. They
can do that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
- Split Wine into 20 packages. A distro can use wine-meta-distro
to do build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
- Split into 20 packages and deal with them without wine-meta-distro
packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free.
Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
Pretty much 5, I think. If I understand correctly, 6 is only true when distributions are already shipping mingw packages (and only for those packages), in which case they're not really redoing any work.
The other important part of 5 is that you can build all those packages in a combination of versions that are tested and guaranteed by community to work (unless packager chooses to do otherwise). My understanding is that you meant packagers to do arbitrary version choices by default.
I'm not admittedly sure what's meant by arbitrary version choices, or perhaps this paragraph in general, but I'm imagining that mingw packages will be no different than non-mingw packages in most respects, so we/distributions can do whatever testing is desired.
If you expect packagers to build 20 packages, they need to make 20 version choices about version and then update them as they see the fit.
Maybe, but the alternative is "let the Wine project make all of those decisions". And if they'd rather trust the versions we propose, then it wouldn't matter how the packages are built.
I don't work in distributions, but I don't particularly understand why 5 is any harder than 2-4, or what's gained from having 2-4 as an option.
The gain from 2-4 is simplicity that I mentioned earlier, which I think is crucial if we want wide adaptation. What's gained by 5?
Essentially, that it's the way things are already done.
I guess I'm also still not understanding why 2-4 is simpler, except I guess it doesn't require any packages to be installed as build dependencies—which doesn't seem like a huge advantage, since that's basically just the norm for package building.
Let's use an example. Suppose I want to bootstrap a fully working Wine on a distro with no Wine or Wine-specific packages (or I just don't want to use them). I don't want to use any binary blob, so I need to build all PE dependences myself. How would my experience look like with what you propose?
Well, in general, someone like me who's not interested in hacking on any PE libraries would retrieve precompiled libraries from WineHQ or distribution repositories—just like installing regular devel packages, just with a different architecture—and then build Wine the same way as is currently done (configure, make, make install).
If one insists on compiling everything themself, they'd go through the same process as they would with any other package. I don't see why wanting to manually compile every PE dependency would be any more likely with Wine than other software, or why it should be treated any differently.
Jacek
On 14.04.2020 03:35, Zebediah Figura wrote:
I don't work in distributions, but I don't particularly understand why 5 is any harder than 2-4, or what's gained from having 2-4 as an option.
The gain from 2-4 is simplicity that I mentioned earlier, which I think is crucial if we want wide adaptation. What's gained by 5?
Essentially, that it's the way things are already done.
I guess I'm also still not understanding why 2-4 is simpler, except I guess it doesn't require any packages to be installed as build dependencies—which doesn't seem like a huge advantage, since that's basically just the norm for package building.
Let's use an example. Suppose I want to bootstrap a fully working Wine on a distro with no Wine or Wine-specific packages (or I just don't want to use them). I don't want to use any binary blob, so I need to build all PE dependences myself. How would my experience look like with what you propose?
Well, in general, someone like me who's not interested in hacking on any PE libraries would retrieve precompiled libraries from WineHQ or distribution repositories—just like installing regular devel packages, just with a different architecture—and then build Wine the same way as is currently done (configure, make, make install).
So, well, binary blobs.
If one insists on compiling everything themself, they'd go through the same process as they would with any other package.
I guess that answers your question about why 2-4 is simpler. This is not as much about insisting as those are real challenges that may be potentially faced by forks like Proton, CrossOver or any other.
I don't see why wanting to manually compile every PE dependency would be any more likely with Wine than other software, or why it should be treated any differently.
We will have to agree to disagree on that. In my opinion expectation to provide SDL2 shared by thousands application is something different than Wine expecting distros to provide an independent cross compiled SDL2 package of acceptable version specifically for Wine.
Jacek
On 4/13/20 9:16 PM, Jacek Caban wrote:
On 14.04.2020 03:35, Zebediah Figura wrote:
I don't work in distributions, but I don't particularly understand why 5 is any harder than 2-4, or what's gained from having 2-4 as an option.
The gain from 2-4 is simplicity that I mentioned earlier, which I think is crucial if we want wide adaptation. What's gained by 5?
Essentially, that it's the way things are already done.
I guess I'm also still not understanding why 2-4 is simpler, except I guess it doesn't require any packages to be installed as build dependencies—which doesn't seem like a huge advantage, since that's basically just the norm for package building.
Let's use an example. Suppose I want to bootstrap a fully working Wine on a distro with no Wine or Wine-specific packages (or I just don't want to use them). I don't want to use any binary blob, so I need to build all PE dependences myself. How would my experience look like with what you propose?
Well, in general, someone like me who's not interested in hacking on any PE libraries would retrieve precompiled libraries from WineHQ or distribution repositories—just like installing regular devel packages, just with a different architecture—and then build Wine the same way as is currently done (configure, make, make install).
So, well, binary blobs.
If one insists on compiling everything themself, they'd go through the same process as they would with any other package.
I guess that answers your question about why 2-4 is simpler. This is not as much about insisting as those are real challenges that may be potentially faced by forks like Proton, CrossOver or any other.
I'm moderately familiar with the build process for Proton, and I don't *think* it would actually be necessary to build any packages, provided that our mingw libraries can be installed in the host VMs.
I'm not familiar with the build process for CrossOver, though. But if CrossOver—or any similar software—doesn't build and distribute all of those libraries already, then would it be possible to depend on mingw libraries in the same way that it depends on linux libraries? Failing that, could they distribute .deb &c. files directly, or even .dll files copied from our mingw packages? (Much like a Windows program would.)
I don't see why wanting to manually compile every PE dependency would be any more likely with Wine than other software, or why it should be treated any differently.
We will have to agree to disagree on that. In my opinion expectation to provide SDL2 shared by thousands application is something different than Wine expecting distros to provide an independent cross compiled SDL2 package of acceptable version specifically for Wine.
Which is why I'm not really looking at it from the perspective that we should expect distributions to build those packages rather than the Wine project.
Jacek
On 14.04.2020 04:27, Zebediah Figura wrote:
On 4/13/20 9:16 PM, Jacek Caban wrote:
On 14.04.2020 03:35, Zebediah Figura wrote:
> I don't work in distributions, but I don't particularly > understand why 5 > is any harder than 2-4, or what's gained from having 2-4 as an > option.
The gain from 2-4 is simplicity that I mentioned earlier, which I think is crucial if we want wide adaptation. What's gained by 5?
Essentially, that it's the way things are already done.
I guess I'm also still not understanding why 2-4 is simpler, except I guess it doesn't require any packages to be installed as build dependencies—which doesn't seem like a huge advantage, since that's basically just the norm for package building.
Let's use an example. Suppose I want to bootstrap a fully working Wine on a distro with no Wine or Wine-specific packages (or I just don't want to use them). I don't want to use any binary blob, so I need to build all PE dependences myself. How would my experience look like with what you propose?
Well, in general, someone like me who's not interested in hacking on any PE libraries would retrieve precompiled libraries from WineHQ or distribution repositories—just like installing regular devel packages, just with a different architecture—and then build Wine the same way as is currently done (configure, make, make install).
So, well, binary blobs.
If one insists on compiling everything themself, they'd go through the same process as they would with any other package.
I guess that answers your question about why 2-4 is simpler. This is not as much about insisting as those are real challenges that may be potentially faced by forks like Proton, CrossOver or any other.
I'm moderately familiar with the build process for Proton, and I don't *think* it would actually be necessary to build any packages, provided that our mingw libraries can be installed in the host VMs.
That's a possibility, but I don't consider that to be nice nor technically correct solution.
I'm not familiar with the build process for CrossOver, though. But if CrossOver—or any similar software—doesn't build and distribute all of those libraries already, then would it be possible to depend on mingw libraries in the same way that it depends on linux libraries? Failing that, could they distribute .deb &c. files directly, or even .dll files copied from our mingw packages? (Much like a Windows program would.)
I don't think analysing existing build systems is relevant here, they are not yet facing the situation we will put them in. By making sure that they can easily replicate what upstream Wine does we can ensure that they are able to reuse upstream Wine work. They may choose to use it or not.
I don't see why wanting to manually compile every PE dependency would be any more likely with Wine than other software, or why it should be treated any differently.
We will have to agree to disagree on that. In my opinion expectation to provide SDL2 shared by thousands application is something different than Wine expecting distros to provide an independent cross compiled SDL2 package of acceptable version specifically for Wine.
Which is why I'm not really looking at it from the perspective that we should expect distributions to build those packages rather than the Wine project.
Yes, that explains differences in opinions. I try to ensure that needs of broader Wine community are taken into account and I think that both distros and forks are important parts of the community.
Jacek
On 14/04/2020 05:16, Jacek Caban wrote:
On 14.04.2020 03:35, Zebediah Figura wrote:
I don't work in distributions, but I don't particularly understand why 5 is any harder than 2-4, or what's gained from having 2-4 as an option.
The gain from 2-4 is simplicity that I mentioned earlier, which I think is crucial if we want wide adaptation. What's gained by 5?
Essentially, that it's the way things are already done.
I guess I'm also still not understanding why 2-4 is simpler, except I guess it doesn't require any packages to be installed as build dependencies—which doesn't seem like a huge advantage, since that's basically just the norm for package building.
Let's use an example. Suppose I want to bootstrap a fully working Wine on a distro with no Wine or Wine-specific packages (or I just don't want to use them). I don't want to use any binary blob, so I need to build all PE dependences myself. How would my experience look like with what you propose?
Well, in general, someone like me who's not interested in hacking on any PE libraries would retrieve precompiled libraries from WineHQ or distribution repositories—just like installing regular devel packages, just with a different architecture—and then build Wine the same way as is currently done (configure, make, make install).
So, well, binary blobs.
If one insists on compiling everything themself, they'd go through the same process as they would with any other package.
I guess that answers your question about why 2-4 is simpler. This is not as much about insisting as those are real challenges that may be potentially faced by forks like Proton, CrossOver or any other.
I don't see why wanting to manually compile every PE dependency would be any more likely with Wine than other software, or why it should be treated any differently.
We will have to agree to disagree on that. In my opinion expectation to provide SDL2 shared by thousands application is something different than Wine expecting distros to provide an independent cross compiled SDL2 package of acceptable version specifically for Wine.
Jacek
I agree. As an example, one of the nice things about the GCC build process—or even bootstrapping MinGW itself—is that it can actually build everything it needs if you just drop the required dependencies in their proper locations (very similar to submodules but slightly more manual if you just use their tarballs and no vcs).
Now, I'm totally fine if the dependencies were built as a separate step, as long as all of them are done in one step, though. That's the key here, to simplify the entire build process. At least, that's what I'd prefer.
So I think I may have misunderstood or lost sight of goals somewhere along the way, let me try to review.
I think it makes the most sense to use one or more separate distribution packages for our PE dependencies, rather than distributing them as part of Wine, statically linking, or distributing them using our Win32-based addons system. I'm not sure just from reading this thread there's a general consensus regarding that, but I'm not sure I've seen anyone argue against it either.
Separately, I think it makes sense for Wine's libraries—seeing as they *are* (relatively, and mostly) high-level—to use MinGW libraries the same as any other MinGW-compiled program would.
It's not clear to me that this implies that we reverse the direction we're currently taking and try to make more use of the MinGW CRT, headers, and/or libraries. (I can understand the CRT part, though even then I have to wonder if there are differences that will matter.)
If it does, I'd like to understand why that's not possible, because it seems to me that we gave up on MinGW after they objected to taking the entire mingw-w64 project under the umbrella of Wine (and I don't think that was a reasonable thing for us to ask, given that mingw-w64's purpose is not to target Wine, but any conforming implementation of the Win32 API, and in practice mostly Windows.)
Now, on the assumption that using mingw-w64-compiled PE libraries is a reasonable thing to do...
On 4/13/20 11:38 AM, Jacek Caban wrote:
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- Use wine-core the way distro currently do to provide Wine package.
Use wine-meta-distro to build Wine addons as one but separated package.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- Like 2 or 3, but distro wants some customization itself. They can do
that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
- Split Wine into 20 packages. A distro can use wine-meta-distro to do
build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
- Split into 20 packages and deal with them without wine-meta-distro
packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free. Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
As a side note, a different and separated distro packages for, say, libxml2 built with winegcc could also have some use cases. That would be something potentially useful for cross compiling an application using winegcc, but not something for Wine to use internally.
I think 2/4 are referring to the same thing (at any rate, I see no reason not to give distributions the choice). I don't think I fully understand how 3 differs from 2/4, or how 6 differs from 5. Do you mean by introducing a meta-package which only exists for dependency purposes?
Anyway, if depending on mingw-w64 really is a dead end, I guess either 4 or 5 seems reasonable to me, though it's less clear that distributions actually would prefer 4. In particular, I notice:
* Suppose you want the versions of the PE libraries you ship to match the ELF libraries your distribution already ships. You can change the sources without too much difficulty, but how do you label the resulting package with regard to version? Naming it after the Wine version isn't great, especially if you're going to update those packages asynchronously...
* If a distribution (or even WineHQ) wants to update one of our 20+ packages, do they/we have to ship the whole wine-meta-distro again? (Maybe this isn't a problem, if the packages in question support partial updates...)
Ultimately I think this is something that actual distributors would have to answer, and I think we should probably bring some in on this thread.
If on the other hand we can depend on mingw-w64 libraries, I think we almost have to pick 5 over 4, for the simple reason that it's already done that way. There's an existing demand for mingw-w64 libraries which are distributed separately. Fedora already ships them. Arch doesn't (in fact, Arch doesn't even ship the mingw-w64 compiler), but they exist in the AUR as separate packages, and I myself use a third-party repository that ships mingw-w64 library blobs. (That's how I was able to write that msxml3 patch, in fact.) Debian/Ubuntu don't ship very many, but they do ship libz, and also development versions of a few other libraries.
Cheers,
Jacek
On 15.04.2020 21:29, Zebediah Figura wrote:
So I think I may have misunderstood or lost sight of goals somewhere along the way, let me try to review.
I think it makes the most sense to use one or more separate distribution packages for our PE dependencies, rather than distributing them as part of Wine, statically linking, or distributing them using our Win32-based addons system. I'm not sure just from reading this thread there's a general consensus regarding that, but I'm not sure I've seen anyone argue against it either.
Separately, I think it makes sense for Wine's libraries—seeing as they *are* (relatively, and mostly) high-level—to use MinGW libraries the same as any other MinGW-compiled program would.
It's not clear to me that this implies that we reverse the direction we're currently taking and try to make more use of the MinGW CRT, headers, and/or libraries. (I can understand the CRT part, though even then I have to wonder if there are differences that will matter.)
If it does, I'd like to understand why that's not possible, because it seems to me that we gave up on MinGW after they objected to taking the entire mingw-w64 project under the umbrella of Wine
Let's make it clear: there is no give up. Cooperation goes on, just like it did before. It just didn't change. We continue to use mingw to build Wine, we just don't use a few static libraries that we didn't need anyway.
To give you an example for the context, look at another prominent mingw-w64: Cygwin. For obvious reason they are interested in Win32 platform and use mingw-w64 for platform headers and importlibs. But they have their own ABI, for which they provide their own C runtime libraries. mingw-w64 allows that, the build system has special features to make such things possible. Cygwin also offers mingw-w64 in a form of a cross compiler, which cross compiles from Cygwin ABI as a host to mingw ABI target (obviously using mingw crt). It's an extreme example why "PE is all the same" in not true.
That analogy also applies to Wine in a more delicate way. msvcrt/ucrtbase implements a crt for msvc ABI, which is very similar, but different than mingw ABI. Wine needs to provide msvcrt anyway for obvious reasons and that's about all we need as for crt.
mingw uses ABI that is slightly different, which has quite a few implications for crt. It's a mixture of static libs and msvcrt importlib with some features that are less than obvious. For example mingw has a real long double which on msvc is the same as double. For that reason, mingw-w64 crt can't use msvcrt long double functions, but instead provides its own implementations of relevant functions in a static lib. If you want full support for long double, you may even choose to use *printf functions provided by mingw-w64 that support long double formats (and also other standard compliance, which was handy at a time, but not so much with ucrt around).
long double is obviously not a blocker, it's just an example to give you high level understanding what mingw-w64 crt really is and why. Now, look what fully using mingw-w64 for crt means part by part:
- mingw-w64 crt headers.
Wine has its own msvcrt headers that could not be blindly just replaced. For example we need those headers to work on non-mingw compilers (like for ELF builds). We'd need make mingw-w64 worry about platform it otherwise doesn't need to care. It's doable, but it's not clear if worth it.
- mingw-w64 msvcrt importlib
As explained at importlib level a lot of functions are implemented in static lib instead of importing from DLL. We provide importlib in form of .spec file anyway.
- standard compatibility stuff
mingw-w64 has a number of features providing standard compliance in places where msvcrt did bad job. It was handy in the past for msvcrt version that were rather bad. It's not so useful on top of ucrt.
- compatibility stuff
A lot of functions are in static lib for compatibility with old msvcrt versions that didn't provide them. A lot of those are just manual delay loads with some static fallbacks. We don't need those.
- more advanced startup files, a few features that really belong to static lib like atexit
We don't need any of those for Wine itself. We may need some in the future.
I hope that answers your question about crt part. If you still think there is a problem, please be more concrete.
That said, there is definitely room for improvements. I happen to be the one maintaining sharing that actually happens for years (which is why I find it ironic that you complain to me about lack of sharing) and I plan to continue doing so. Let me use a chance to raise awareness in case someone wants to help. mingw-w64 semi-automatically imports a number of headers and widl from Wine tree. On mingw-w64 side there is assumption that for imported stuff, Wine review replaces mingw-w64 review process. mingw-w64 has two import scripts that are really basic and trivial to maintain scripts doing the job. If you'd prefer to do it differently, patches welcomed.
We could share a lot more platform headers, but it's a real work. In case a header is missing in mingw-w64, it's a matter of testing and making sure all its dependences are fine. If it's already duplicated between projects, then deduplication needs a review to make sure that one of copies is complete enough to replace the other by sending a patch to Wine. Once it's in Wine, send a patch to import script to mingw-w64. From this moment, both repos will stay synced. If you hypothetically want fully merged platform headers in the future, this is the way to do it incrementally. And it's already there.
widl could also use some work. The most notable example that sees demand on mingw-w64 side is better winrt support.
If you really want to help mingw-w64 and Wine, I think that contributing to any of above is a good way to do it.
Now, on the assumption that using mingw-w64-compiled PE libraries is a reasonable thing to do...
On 4/13/20 11:38 AM, Jacek Caban wrote:
So let me give a few examples of different choices packagers can do. I will call wine-core Wine as we know today (which will not change architecturally) and wine-meta-distro the proposed separated repo for dependencies build system allowing a simple and straightforward way to bootstrap complete Wine+dependences package, depending only on cross compilation tools.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- Use wine-core the way distro currently do to provide Wine package.
Use wine-meta-distro to build Wine addons as one but separated package.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- Like 2 or 3, but distro wants some customization itself. They can
do that, for example, by pointing wine-meta-distro to its own version of relevant package, pass additional config options or do simple source code modifications.
- Split Wine into 20 packages. A distro can use wine-meta-distro to
do build config stuff, so that they don't need to change their scripts every time something changes in any of dependent packages, but otherwise treat every dependency as a separated package.
- Split into 20 packages and deal with them without wine-meta-distro
packages. This will require packagers to redo all the work that packagers choosing 1-5 will be getting for free. Your proposal seems to be similar to something between 5 and 6. I don't expect packagers to be thrilled with that idea if they have 2-4 as alternatives, by the key point is: let's give them a choice.
As a side note, a different and separated distro packages for, say, libxml2 built with winegcc could also have some use cases. That would be something potentially useful for cross compiling an application using winegcc, but not something for Wine to use internally.
I think 2/4 are referring to the same thing (at any rate, I see no reason not to give distributions the choice). I don't think I fully understand how 3 differs from 2/4, or how 6 differs from 5. Do you mean by introducing a meta-package which only exists for dependency purposes?
Anyway, if depending on mingw-w64 really is a dead end, I guess either 4 or 5 seems reasonable to me, though it's less clear that distributions actually would prefer 4. In particular, I notice:
- Suppose you want the versions of the PE libraries you ship to match
the ELF libraries your distribution already ships. You can change the sources without too much difficulty, but how do you label the resulting package with regard to version? Naming it after the Wine version isn't great, especially if you're going to update those packages asynchronously...
It's not very important implementation detail that we may decide once we have it sorted out on higher level.
- If a distribution (or even WineHQ) wants to update one of our 20+
packages, do they/we have to ship the whole wine-meta-distro again? (Maybe this isn't a problem, if the packages in question support partial updates...)
Well, just like we'd update jscript.dll in Wine installation even if it didn't change since last update.
Ultimately I think this is something that actual distributors would have to answer, and I think we should probably bring some in on this thread.
If on the other hand we can depend on mingw-w64 libraries, I think we almost have to pick 5 over 4, for the simple reason that it's already done that way. There's an existing demand for mingw-w64 libraries which are distributed separately. Fedora already ships them. Arch doesn't (in fact, Arch doesn't even ship the mingw-w64 compiler), but they exist in the AUR as separate packages, and I myself use a third-party repository that ships mingw-w64 library blobs. (That's how I was able to write that msxml3 patch, in fact.) Debian/Ubuntu don't ship very many, but they do ship libz, and also development versions of a few other libraries.
Let me give a high level summary how I see it. I'm not attached to what I proposed, but here is how I can see the situation:
We're going to be shipping PE build ourselves one way or another (all solutions assume that so far). Whatever form that will take, we should make sure that it's something reusable for others. By ensuring that whatever we do is easy to reuse, we can make sure that forks and distros have the ability to do the same without duplicating efforts.
I think that the solution should be portable. Limiting it to a distro or a set of distros is not what I consider as portable. We will want to provide distro packages, just like we provide Wine packages. But I think that actual maintenance should be happening in platform-independent place. Just like Wine has no bits specific to any package manager in its sources.
It seems to me that autoconf and make provide tools to achieve that.
Jacek
Hi all,
I experimented with using winegcc to build Wine dependences lately with promising results. I put up a proof of concept repo here:
https://github.com/cjacek/wine-addons
It only takes care of building winefreetype.dll and winefaudio.dll currently. No installation or Wine integration is implemented, it's just a convenient tool to play with the build at the moment. It takes care of linking DLLs by ourselves. I experimented and eventually got it working using dependencies build system to output a shared library, but it was both more messy and didn't give a nice way to do renaming.
Ideally, it would work just fine by running plain configure if you have Wine installed already. It does not work yet because Wine does not install cross importlibs yet. Instead, a build directory is required, so one has to provide at least --with-wine-tools=... --with-wine-srcdir=... for now.
I tested it with PE dwrite build and it passed all tests. Opinions are welcomed.
Cheers,
Jacek
-
Erich E. Hoover -
Esme (they/them) -
Esme Povirk (they/them)
-
Gabriel Ivăncescu -
Jacek Caban -
Marvin -
Rémi Bernon -
Vincent Povirk (they/them)
-
Zebediah Figura