On 4/20/22 04:13, Richard W.M. Jones wrote:
On Mon, Apr 11, 2022 at 11:18:17PM -0500, Zebediah Figura wrote:
> On 4/11/22 08:50, Michael Cronenworth wrote:
>> On 4/10/22 8:28 PM, Zebediah Figura wrote:
>>> The first problem is that the location of runtime DLLs varies
>>> wildly between distributions, and there's no common independent
>>> way to detect it. We could potentially hardcode a few "guesses"
>>> at the runtime path into Wine's configure script, but that
>>> brings us to the second problem: there's no way to verify the
>>> presence of runtime DLLs. We *are* the loader and lower-level
>>> APIs and would have to bootstrap ourselves first, and this is
>>> pretty much infeasible.
>>
>> What does that variance between distros look like?
>
> Fedora and SuSE put all binaries, including libgcc binaries, in
> /usr/<arch>-w64-mingw32/sys-root/mingw/bin/.
>
> Debian puts normal libraries in /usr/<arch>-w64-mingw32/lib/, and
> libgcc binaries in
> /usr/lib/gcc/<arch>-w64-mingw32/<version>-<variant>/, where
> <version> is currently 10 and <variant> is win32 or posix.
>
> Arch (well, the AUR) puts all binaries in /usr/<arch>-w64-mingw32/bin/.
Can't this just be yet another Wine ./configure flag? It's trivial
for the Fedora spec to set this correctly (using %{mingw64_sysroot}
from mingw{32,64}-filesystem).
Sorry for missing this reply. This is the current purpose of the
--with-system-dllpath flag, as I had described earlier in the same mail.
It's just a bit unfortunate because it means that MinGW packages can't
be automatically picked up by a user trying to compile Wine from source.