Hi, Adding smcv to the thread.
Le mar. 7 sept. 2021 à 23:25, Bastien ROUCARIES <roucaries.bast...@gmail.com> a écrit : > > Le mar. 7 sept. 2021 à 21:16, Zebediah Figura > <zfig...@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 <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. > > > > > > > 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
