[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wine MinGW system libraries



Le mar. 7 sept. 2021 à 21:16, Zebediah Figura
<zfigura@codeweavers.com> a écrit :
>
> On 9/7/21 12:05 PM, Bastien ROUCARIES wrote:
> > 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.
> >
>
> Ah, so what you're proposing is that we do some sort of objcopy-like
> patching at runtime, e.g. when copying the dependency into the prefix.
>
> It probably won't be easy, but it might be more feasible than modifying
> the loader. I'll look into it...
Yes sort of obcopy patching under linux it is called patchelf...

If it work, it could be latter done in memory like paul wise suggest
implementing namespace and LT_AUDIT (but it is a long term goal)
1. capture library loading
2. do the patching at loading time (using the same code then patchelf
for pe replacing file read/write by mmap operation)

And voila

bastien


Reply to: