Re: Wine MinGW system libraries

From	Bastien ROUCARIES <roucaries.bastien@gmail.com>
Newsgroups	linux.debian.devel
Subject	Re: Wine MinGW system libraries
Date	2021-09-07 20:20 +0200
Message-ID	<CUNRn-7zg-3@gated-at.bofh.it> (permalink)
References	(1 earlier) <CUuOK-3QG-5@gated-at.bofh.it> <CUxtf-5tR-1@gated-at.bofh.it> <CUGGd-3cU-7@gated-at.bofh.it> <CULwd-629-1@gated-at.bofh.it> <CUN4Z-73U-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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

Le mar. 7 sept. 2021 à 19:05, Bastien ROUCARIES <roucaries.bastien@gmail.com>
a écrit :

> I disagree.
>
> Le mar. 7 sept. 2021 à 17:48, Zebediah Figura <zfigura@codeweavers.com> a
> écrit :
>
>> On 9/7/21 5:16 AM, Bastien Roucariès wrote:
>> > Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit :
>> >> On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote:
>> >>> The basic problem is that applications can and often do ship with PE
>> >>> builds of cross-platform libraries. These libraries can be ahead of
>> >>> Wine's system libraries, behind them, or even built with custom
>> patches.
>> >>> Accordingly we really don't want to load "our" freetype in place of
>> >>> "their" freetype, or "theirs" in place of "ours". But because of the
>> way
>> >>> the Win32 loader works, you can generally only have one DLL of a given
>> >>> name loaded in a process, and further attempts to dlopen() [as it
>> were]
>> >>> "libfreetype-6.dll" will return the handle to the already loaded
>> >>> library, potentially breaking either Wine or the application.
>> >>
>> >> I don't know the details here, but my immediate thought when reading
>> >> this is that you need some kind of namespace. I then found that linker
>> >> namespaces are a thing, perhaps they would provide the solution for
>> >> you. It sounds like the OpenGL shim loader solution listed on the
>> >> glibc wiki might work for your use-case. Or perhaps the LD_AUDIT
>> >> feature would also work.
>> >>
>> >> https://www.sourceware.org/glibc/wiki/LinkerNamespaces
>> > I agree with pabs, implementing name space is a good solution
>> > and will allow to be distrib friendly.
>> >
>> > Moreover it will be best if marking a library as wine system one could
>> be done
>> > post build. We will prefer to not modify upstream (like libpng) source.
>> >
>> > It is easier for us to apply small patch to upstream, or better in your
>> case
>> > to add a post link linker script or even some compiler flag that will
>> add some
>> > notes section to dll in order to mark it as use namespace system, or so
>> on.
>> >
>> > The problem on windows side is well known as dll hell
>> >
>> > Renaming of the lib could be done post install. Moreover a crazy idea
>> why not
>> > renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll
>> (note the
>> > version is manadaroty) Therefore we could use  upstream source. Then
>> add a
>> > small linker script that will rewrite the depends of  libpng-2.0.0.sll
>> to
>> > .sll file (aka binary sed s/.dll/.sll/g).
>> >
>> > then add a small wraper (shim) like said pab that load the .sll
>> library, the
>> > best pratice will be a command tool that take the name of the sll and
>> create
>> > magically the dll
>> >
>> > Therefore from distrib point of side we only changes the way we build
>> the
>> > package, it could be automated, it is scalable and it does not need to
>> patch
>> > package by package. Only to add some linker script magic
>>
>> The problem isn't particularly about detecting what is and isn't a
>> system library; I think we can come up with a reliable heuristic for
>> that, without even needing linker namespaces or anything.
>>
>> 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.
>>
>> It may also be that the aforementioned heuristic is too hacky to be
>> accepted upstream into Wine.
>>
> I do not propose to change the loader, i propose to change the link or
> post link stage of system library. You could rename the lib and change the
> dépend to new name after build. So you will have an unique name per system
> lib without changing the way you build these lib.
>
> It is équivalent to use a namespace resolved at late build time.
>
And it is already coded :)

https://pypi.org/project/machomachomangler/

>
>

Thread

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

csiph-web