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/.
Why can't we (or others) standardize a location? Fedora/RHEL and
Debian/Ubuntu are upstreams for a majority of distributions. If we
create a standard they'll fall in line.
We could, and it might be a good idea regardless. The problem where Wine
is concerned is that ideally if one successfully builds from source, the
program shouldn't fail to run for unclear reasons (along the lines of
"unable to locate zlib1.dll"). If we just assume that binaries are in a
standard location, that'll happen for any distributions or environments
that don't (yet) follow the standard.
(It also occurs to me that since Debian ships multiple threading
variants, it's not necessarily as trivial as "put everything in
/usr/<arch>-w64-mingw32/bin/" either, although that might end up being a
trivial symlink...)