I disagree.
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.