Re: Wine MinGW system libraries
Hi,
Adding smcv to the thread.
Le mar. 7 sept. 2021 à 23:25, Bastien ROUCARIES
<roucaries.bastien@gmail.com> a écrit :
>
> 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
Simon, do you think you could implement a version of libcapasule for PE object ?
Bastien
> bastien
Reply to: