Le mar. 7 sept. 2021 à 19:05, Bastien ROUCARIES <roucaries.bast...@gmail.com> a écrit :
> I disagree. > > Le mar. 7 sept. 2021 à 17:48, Zebediah Figura <zfig...@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/ > >
