Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #101547 > unrolled thread

Wine MinGW system libraries

Back to article view | Back to linux.debian.devel

Contents

  Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-05 03:40 +0200
    Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-05 09:20 +0200
      Re: Wine MinGW system libraries Stephen Kitt <skitt@debian.org> - 2021-09-05 18:30 +0200
      Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-12 10:00 +0200
        Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-12 15:40 +0200
          Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-12 16:10 +0200
            Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-12 16:20 +0200
              Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-12 16:40 +0200
                Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-12 17:20 +0200
                  Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-12 17:30 +0200
              Re: Wine MinGW system libraries Helmut Grohne <helmut@subdivi.de> - 2021-09-13 17:50 +0200
                Re: Wine MinGW system libraries Stephen Kitt <skitt@debian.org> - 2021-09-13 20:20 +0200
                  Re: Wine MinGW system libraries Helmut Grohne <helmut@subdivi.de> - 2021-09-13 22:10 +0200
                  Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-13 22:30 +0200
                    Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-13 23:00 +0200
                      Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-13 23:40 +0200
        Re: Wine MinGW system libraries Stephen Kitt <skitt@debian.org> - 2021-09-12 17:40 +0200
          Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-12 18:40 +0200
            Re: Wine MinGW system libraries Stephen Kitt <skitt@debian.org> - 2021-09-12 19:10 +0200
              Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-12 20:20 +0200
                Re: Wine MinGW system libraries Stephen Kitt <skitt@debian.org> - 2021-09-13 20:30 +0200
    Re: Wine MinGW system libraries Stephen Kitt <skitt@debian.org> - 2021-09-05 18:20 +0200
      Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-05 19:20 +0200
        Re: Wine MinGW system libraries Stephen Kitt <skitt@debian.org> - 2021-09-06 09:10 +0200
          Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-06 10:20 +0200
          Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-06 18:40 +0200
            Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-06 21:00 +0200
              Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-07 00:00 +0200
                Re: Wine MinGW system libraries Paul Wise <pabs@debian.org> - 2021-09-07 02:50 +0200
                  Re: Wine MinGW system libraries "Bastien Roucariès" <roucaries.bastien@gmail.com> - 2021-09-07 12:40 +0200
                    Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-07 17:50 +0200
                      Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-07 19:30 +0200
                        Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-07 20:20 +0200
                        Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-07 23:20 +0200
                          Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-08 01:50 +0200
                            Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-08 09:50 +0200
                              Re: Wine MinGW system libraries Simon McVittie <smcv@debian.org> - 2021-09-08 10:20 +0200
                                Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-08 17:50 +0200
                                  Re: Wine MinGW system libraries Paul Wise <pabs@debian.org> - 2021-09-09 03:20 +0200
                                    Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-09 06:50 +0200
                                      Re: Wine MinGW system libraries Paul Wise <pabs@debian.org> - 2021-09-09 07:20 +0200
                                        Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-09 07:40 +0200
                                          Re: Wine MinGW system libraries Paul Wise <pabs@debian.org> - 2021-09-09 07:50 +0200
                                            Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2021-09-09 08:10 +0200
                                              Re: Wine MinGW system libraries Paul Wise <pabs@debian.org> - 2021-09-09 09:40 +0200
                                                Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-10 11:50 +0200
                                                  Re: Wine MinGW system libraries Paul Wise <pabs@debian.org> - 2021-09-11 08:10 +0200
                                                    Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-12 17:20 +0200
                      Re: Wine MinGW system libraries Paul Wise <pabs@debian.org> - 2021-09-08 01:10 +0200
                        Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-08 01:30 +0200
    Re: Wine MinGW system libraries Adrian Bunk <bunk@debian.org> - 2021-09-11 17:40 +0200
      Re: Wine MinGW system libraries Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-09-11 20:10 +0200
    Re: Wine MinGW system libraries Zebediah Figura <zfigura@codeweavers.com> - 2022-04-17 02:30 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#101612

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2021-09-08 at 23:47 -0500, Zebediah Figura wrote:

> Unfortunately, while thinking about the answer to this question, I 
> realized another snag, which I think really does make using 
> identically-named dynamic libraries impossible: if system library A 
> loads system library B dynamically, i.e. does the equivalent of a 
> dlopen(), we have no way of knowing which namespace to apply to it. 
> [AFAICT dlmopen() has this problem too, and just isn't meant for that
> use case.] Even rewriting the import table doesn't help here.

While loading library A into a namespace Foo, the loader could set a
process global variable containing the current namespace to load into,
and then have the dlopen equivalent use namespace Foo in preference to
the default namespace for the process. Then when library B is loaded it
will go into namespace Foo. Once loading library B and A has completed
the loader could revert to using the default namespace.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101613

On 9/9/21 12:15 AM, Paul Wise wrote:
> On Wed, 2021-09-08 at 23:47 -0500, Zebediah Figura wrote:
> 
>> Unfortunately, while thinking about the answer to this question, I
>> realized another snag, which I think really does make using
>> identically-named dynamic libraries impossible: if system library A
>> loads system library B dynamically, i.e. does the equivalent of a
>> dlopen(), we have no way of knowing which namespace to apply to it.
>> [AFAICT dlmopen() has this problem too, and just isn't meant for that
>> use case.] Even rewriting the import table doesn't help here.
> 
> While loading library A into a namespace Foo, the loader could set a
> process global variable containing the current namespace to load into,
> and then have the dlopen equivalent use namespace Foo in preference to
> the default namespace for the process. Then when library B is loaded it
> will go into namespace Foo. Once loading library B and A has completed
> the loader could revert to using the default namespace.

Right, but we don't have any guarantee that library A will load library 
B in its constructor routines. In fact, if it's loading library B 
dynamically, it's probably not doing that.

[toc] | [prev] | [next] | [standalone]

#101614

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2021-09-09 at 00:39 -0500, Zebediah Figura wrote:

> Right, but we don't have any guarantee that library A will load library 
> B in its constructor routines. In fact, if it's loading library B 
> dynamically, it's probably not doing that.

Can the loader tell which library asked it to load a library?
Then the namespace could be inherited from the parent library.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101615

On 9/9/21 12:45 AM, Paul Wise wrote:
> On Thu, 2021-09-09 at 00:39 -0500, Zebediah Figura wrote:
> 
>> Right, but we don't have any guarantee that library A will load library
>> B in its constructor routines. In fact, if it's loading library B
>> dynamically, it's probably not doing that.
> 
> Can the loader tell which library asked it to load a library?
> Then the namespace could be inherited from the parent library.
> 

Unfortunately, no. We have no way of knowing the caller.

[toc] | [prev] | [next] | [standalone]

#101617

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2021-09-09 at 00:59 -0500, Zebediah Figura wrote:

> Unfortunately, no. We have no way of knowing the caller.

Can the PE loading mechanism do something like inject a fake dlopen
function available only in the Wine namespace that just passes the Wine
namespace to the dlmopen function? Or the same but for each library?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101632

Le jeu. 9 sept. 2021 à 07:32, Paul Wise <pabs@debian.org> a écrit :
>
> On Thu, 2021-09-09 at 00:59 -0500, Zebediah Figura wrote:
>
> > Unfortunately, no. We have no way of knowing the caller.
>
> Can the PE loading mechanism do something like inject a fake dlopen
> function available only in the Wine namespace that just passes the Wine
> namespace to the dlmopen function? Or the same but for each library?

The problem is that windows apps particularly games try to check if
mapped ram exec pages are from dll from disk and not modified in
memory.

Thus if we create namespace, this crappy software will stop to work
except if we create or symlink a library with an unique name that the
wine applications could fetch

Note that windows use for libraryname only the basename not the
fullpatch (zebediah could you confirm)

I am proposing (for simplicity I call the problematic lib libpng that
depends on libz)
1. build like usual a libpng and libz. libpng depend on linbz
2. copy libpng to libwinepng and libz to libwinez
3 use a new patchpe command (like the patchelf command) to patch the
depend of libwinepng
So globally a post link time namespace (it will be better on debian
side than to recompile and pass flags to library).

You  propose:
1. build like usual a libpng and libz. libpng
2 create symlink libwinepng -> libpng, liwinez->libz
3. instruct the loader to load libwinepng privatly using namespace
approach and do at run time the patchpe work

I believe that your approach is technically superior but could be done
on the top of my first approach and a second step.

Zebediah could you please give use feedback from wine team ?

If patchpe is workable (and I firmly believe it is), you could add a
task to see if paul wise solution is workable and report here.

Next step, will be to refine your proposal. For instance i really
dislike the libpng libwinepng mapping I will prefer a mapping given as
perlre
and something that encode the wine ABI like s/^lib/lib-wineinternaluseABI1.0/g

It will allow to create pkgconfig file for wine version of lib automatically

Bastien
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101650

[Multipart message — attachments visible in raw view] — view raw

Disclaimer: I know precisely zero of the details here nor
if the PE loader can support any of the below features.

On Fri, 2021-09-10 at 09:23 +0000, Bastien ROUCARIES wrote:

> The problem is that windows apps particularly games try to check if
> mapped ram exec pages are from dll from disk and not modified in
> memory.

The fake dlopen could presumably be provided by an on-disk DLL?
The PE loader would just load the fake dlopen DLL first, like
glibc does when you set the LD_PRELOAD environment variable.

> You propose:

I'm not proposing any on-disk symlinks, renaming DLLs or any other
changes to any PE DLLs, just loading into memory like dlmopen.

The solution I'm thinking of looks something like this:

src:libpng -> libpng16-16:$winarch -> /usr/lib/$wintriplet/libpng16.dll
(requires Debian to support cross-only, partial and Windows arch types)

PE loader sets up in-memory Wine namespace.

PE loader loads into Wine namespace: /usr/lib/$windowstriplet/wine/fake-dlopen.dll

PE loader loads Wine dependencies into Wine namespace.

Some of the Wine dependencies call the Windows equivalent of dlopen,
which resolves to the fake dlopen equivalent within the namespace,
which calls the Windows equivalent of dlmopen("Wine", dll), which makes
the PE loader load those libraries into the Wine namespace.

PE loader finishes loading Wine dependencies and proceeds loading the
PE file and its dependencies into the default namespace.

Windows apps check mapped RAM pages and they show up correctly.
The main issue would be that apps could check they run in Wine.
OTOH the PE loader could also just hide the pages somehow?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101671

Le sam. 11 sept. 2021 à 06:00, Paul Wise <pabs@debian.org> a écrit :
>
> Disclaimer: I know precisely zero of the details here nor
> if the PE loader can support any of the below features.
>
> On Fri, 2021-09-10 at 09:23 +0000, Bastien ROUCARIES wrote:
>
> > The problem is that windows apps particularly games try to check if
> > mapped ram exec pages are from dll from disk and not modified in
> > memory.
>
> The fake dlopen could presumably be provided by an on-disk DLL?
> The PE loader would just load the fake dlopen DLL first, like
> glibc does when you set the LD_PRELOAD environment variable.
>
> > You propose:
>
> I'm not proposing any on-disk symlinks, renaming DLLs or any other
> changes to any PE DLLs, just loading into memory like dlmopen.
>
> The solution I'm thinking of looks something like this:
>
> src:libpng -> libpng16-16:$winarch -> /usr/lib/$wintriplet/libpng16.dll
> (requires Debian to support cross-only, partial and Windows arch types)
>
> PE loader sets up in-memory Wine namespace.
>
> PE loader loads into Wine namespace: /usr/lib/$windowstriplet/wine/fake-dlopen.dll
>
> PE loader loads Wine dependencies into Wine namespace.
>
> Some of the Wine dependencies call the Windows equivalent of dlopen,
> which resolves to the fake dlopen equivalent within the namespace,
> which calls the Windows equivalent of dlmopen("Wine", dll), which makes
> the PE loader load those libraries into the Wine namespace.
>
> PE loader finishes loading Wine dependencies and proceeds loading the
> PE file and its dependencies into the default namespace.

Seems that python do what you describe:
https://svn.python.org/projects/python/trunk/PC/dl_nt.c
Windows already implemented the name space called activation context.
Need only windows XP or better but wine could offer the API

> Windows apps check mapped RAM pages and they show up correctly.
> The main issue would be that apps could check they run in Wine.
> OTOH the PE loader could also just hide the pages somehow?


>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101573

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2021-09-07 at 10:48 -0500, Zebediah Figura wrote:

> The outstanding problem seems to be more about potentially breaking 
> applications because they see two identically named DLLs loaded in the 
> same process. Applications can and do trawl the internal loader state, 
> although the Win32 loader also exposes some APIs so they don't even have to.

I might be wrong but I got the impression that runtime linker
namespaces & LD_AUDIT are designed to solve this exact issue.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101574

Le mar. 7 sept. 2021 à 23:01, Paul Wise <pabs@debian.org> a écrit :
>
> On Tue, 2021-09-07 at 10:48 -0500, Zebediah Figura wrote:
>
> > The outstanding problem seems to be more about potentially breaking
> > applications because they see two identically named DLLs loaded in the
> > same process. Applications can and do trawl the internal loader state,
> > although the Win32 loader also exposes some APIs so they don't even have to.
>
> I might be wrong but I got the impression that runtime linker
> namespaces & LD_AUDIT are designed to solve this exact issue.
Yes but it does not work for PE because win native application do
messy stuff with lib loader...

see dll hell for instance.

Spec was wrong for the beginning for PE. And wine does not use the ELF
loader but a homemade PE in order to be bug to bug compatible with
windows.

In the long term implementing a LT_AUDIT in the wine loader will be
worthless, but in the short term elfpatch like approach could work.
Python use it.

Bastien
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101657

On Sat, Sep 04, 2021 at 08:17:53PM -0500, Zebediah Figura wrote:
> Hello all,
> 
> I'm a contributor to the Wine project. To summarize the following mail, Wine
> needs special versions of some of its normal dependencies, such as
> libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
> sending out a mail to major distributions in order to get some feedback from
> our packagers on how these should be built and packaged.
> 
> For a long time Wine has built all of its Win32 libraries (DLLs and EXEs) as
> ELF binaries. For various reasons related to application compatibility, we
> have started building our binaries as PE instead, using the MinGW
> cross-compiler. It is our intent to expand this to some of our dependencies
> as well. The list of dependencies that we intend to build using MinGW is not
> quite fixed yet, but we expect it to include and be mostly limited to the
> following:
> 
> * libvkd3d
> * libFAudio
> * libgnutls
> * zlib (currently included via manual source import)
> * libmpg123
> * libgsm
> * libpng
> * libjpeg-turbo
> * libtiff
> * libfreetype
> * liblcms2
> * jxrlib
> 
> and dependencies of the above packages (not including CRT dependencies,
> which Wine provides).
>...
> Accordingly, although static linking and source imports are generally
> disprefered, it may quite likely be preferable in our case. We don't get the
> benefits of on-disk deduplication, since Wine is essentially the only piece
> of software which needs these libraries.
>...

How are distributions supposed to provide security support for Wine?

As an example, Debian 10 that is security supported by Debian
until next summer ships Wine 4.0.

The libgnutls in Debian 10 has already been patched several times
by Debian for CVE fixes.

Having to patch several different versions of the same library
in different packages multiplies the effort required to provide
security support for a library.

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#101660

[Multipart message — attachments visible in raw view] — view raw

Le sam. 11 sept. 2021 à 17:30, Adrian Bunk <bunk@debian.org> a écrit :

> On Sat, Sep 04, 2021 at 08:17:53PM -0500, Zebediah Figura wrote:
> > Hello all,
> >
> > I'm a contributor to the Wine project. To summarize the following mail,
> Wine
> > needs special versions of some of its normal dependencies, such as
> > libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
> > sending out a mail to major distributions in order to get some feedback
> from
> > our packagers on how these should be built and packaged.
> >
> > For a long time Wine has built all of its Win32 libraries (DLLs and
> EXEs) as
> > ELF binaries. For various reasons related to application compatibility,
> we
> > have started building our binaries as PE instead, using the MinGW
> > cross-compiler. It is our intent to expand this to some of our
> dependencies
> > as well. The list of dependencies that we intend to build using MinGW is
> not
> > quite fixed yet, but we expect it to include and be mostly limited to the
> > following:
> >
> > * libvkd3d
> > * libFAudio
> > * libgnutls
> > * zlib (currently included via manual source import)
> > * libmpg123
> > * libgsm
> > * libpng
> > * libjpeg-turbo
> > * libtiff
> > * libfreetype
> > * liblcms2
> > * jxrlib
> >
> > and dependencies of the above packages (not including CRT dependencies,
> > which Wine provides).
> >...
> > Accordingly, although static linking and source imports are generally
> > disprefered, it may quite likely be preferable in our case. We don't get
> the
> > benefits of on-disk deduplication, since Wine is essentially the only
> piece
> > of software which needs these libraries.
> >...
>
> How are distributions supposed to provide security support for Wine?
>
> As an example, Debian 10 that is security supported by Debian
> until next summer ships Wine 4.0.
>
> The libgnutls in Debian 10 has already been patched several times
> by Debian for CVE fixes.
>
> Having to patch several different versions of the same library
> in different packages multiplies the effort required to provide
> security support for a library.
>

Yes what why Paul and myself ask for partial arch. No static linking no
embeded lib but we need answer from upstream.

Note that windows application that use old library are not a concern from
the debian si de

Bastien

>
> cu
> Adrian
>
>

[toc] | [prev] | [next] | [standalone]

#104156

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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.debian.devel

csiph-web