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

Re: Wine MinGW system libraries

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


Reply to: