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