Re: Wine MinGW system libraries
Hello all,
Since this conversation several months ago I've been working with the
Wine maintainer on implementing a solution upstream that is compatible
with our requirements and the pretty much universal desire by packagers
to avoid system library imports. I believe I've found a solution that
will work for now for everyone, although it has raised some questions
about standardization of MinGW packages—see the "Open Questions" section
of this mail for more details.
== Summary of upstream progress ==
Currently Wine bundles the source of several libraries. At the same
time, as was discussed we've implemented a system upstream by which
external shared libraries can be linked to and loaded (while keeping
them in a separate "namespace" so that they don't conflict with
identically named application DLLs.) There are still some concerns on
the Wine side that this will break applications in subtle ways, but
unfortunately there has been almost no testing of this feature yet.
The libraries which we import are as follows:
* libFAudio
* libgsm
* libjpeg
* jxrlib
* liblcms2
* libmpg123
* libpng
* libtiff
* libvkd3d
* libxml2
* libxslt
* zlib
This list is probably going to remain stable. Despite what was discussed
earlier I do *not* forsee us importing libOSMesa (it turns out that it
actually makes more sense on the Win32 "kernel" side). An import of
libfreetype or libgnutls is also unlikely at this point (we've found it
more worthwhile to write thunks for both).
We currently do *not* support external static linking. The basic reason
for this is that Wine builds against its own CRT rather than MinGW's,
and we cannot safely statically link to a module built with a different CRT.
== Technical details ==
In order to use system shared libraries, Wine needs to know where to
find them at runtime. This is done with a configure argument:
configure --with-system-dllpath=/first/directory/:/second/directory/
Note that this may need to include the location of libgcc_s and other
dependencies, which is in a different location on Debian.
Separately, for each argument, we need to know the compiler and linker
flags used to find the library. This also can be done with configure
arguments, much like for native libraries:
configure GSM_PE_CFLAGS="-Iwhatever" GSM_PE_LIBS="-Lwhatever -lgsm"
If MinGW pkg-config is present, and --with-system-dllpath is specified,
Wine will automatically use it to detect the compiler and linker flags
for all of the above packages supporting pkg-config, which in particular
excludes libgsm and jxrlib. Thus in practice it should not be necessary
to hand-code most CFLAGS and LIBS variables.
== Open Question(s) ==
Currently it's necessary to use a configure argument to specify where to
find the runtime path. This is fine for distributions, which is where
most people are going to be getting Wine anyway. It's a bit unfortunate
for anyone self-compiling Wine, though, and it'd be nice if there was
some way to avoid it. Unfortunately, there are two things standing in
our way.
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. Verifying by name doesn't really
work either, since the name isn't really predictable.
Hence "standardize the location of runtime DLLs across distributions"
isn't really a feasible solution either (or at least not a complete
one), as nice as it would be—we have no way to know whether a
distribution is post-standardization or not.
Rather, I think the best solution is to have some tool which, if present
or successful, lists one or more directories where libraries can be
found. I'm not sure what the most sensible thing here is:
* pkg-config would be an obvious tool to extend, but would presumably
require modifying .pc files for all relevant packages upstream. The
location also seems to be consistent across all packages within each
distribution I was able to test, so there probably isn't much point in
making it package-specific. [For the packages we care about, cmake and
libtool both put things in /bin by default, and zlib apparently has no
built-in cross-compilation support.]
* Introducing an analogue of ld.so.conf seems like a good idea. It would
allow for per-package extra directories, and is relatively easy to
parse, although ideally it would be even easier than that (i.e. if
someone else could deal with the "include" part, that would be great).
ἔρρωσθε,
Zeb Figura
Reply to: