Actually, the "clever" solution may be to base any changes in loader behavior on the path of the dll, not how it was loaded. If a library is dynamically loading dependencies on Windows, it's already going to ensure it loads them based on its own location.
On Thu, Sep 9, 2021 at 8:56 AM Esme Povirk (she/they) esme@codeweavers.com wrote:
On Wed, Sep 8, 2021 at 11:39 PM Zebediah Figura zfigura@codeweavers.com wrote:
Actually, while thinking about it I realized another, more salient snag: if system library A tries to load system library B dynamically, we have no way of knowing whether to give it the system or application library.
I don't think there's any way around this. Even rewriting the import table using objcopy or something (which was actually proposed in conversation with distributions) wouldn't fix this. We have to use a different name, or abandon dynamic libraries altogether.
Maybe there's clever solution I'm missing?
If a library needs to do this, then we will have to modify it no matter what solution we use.